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SUMMARY 

This  paper  describes  a  number  of  experiments  in  program  verification  carried  out  within 
two  automated  proof  assistants,  namely  the  HOL  (Higher  Order  Logic)  system  and  Isabelle. 
Various  approaches  to  programming  language  semantics  are  described.  Theories  and 
tactics  for  proving  the  correctness  of  programs  written  in  small  functional  and  imperative 
languages  are  then  constructed  within  HOL  and  Isabelle. 
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Chapter  1  INTRODUCTION 

The  study  of  computing  machines  has  always  ranged  from  the  fundamental  mathematical  approach,  such 
as  computability  and  decidability,  to  more  practical  engineering  concerns,  such  as  the  construction  of 
integrated  circuits.  The  discipline  of  computer  programming  sits  (at  times  uneasily)  between  science  and 
engineering.  In  the  past,  programming  tended  to  be  regarded  as  something  of  a  black  art.  The  early 
programming  languages  (such  as  FORTRAN)  made  it  almost  impossible  to  write  well-structured  and 
easy-to-iinderstand  programs.  If  a  program  happened  to  work  without  crashing,  one  was  relieved. 

Modern  computer  science  is  becoming  more  and  more  a  mathematical  discipline,  with  the  realisation 
that  languages  can  be  carefully  designed  to  enable  well-suaictured  programs  to  be  written,  and  that 
mathematics  is  an  appropriate  arena  for  reasoning  about  computer  programs.  Today  computer  science 
and  software  development  are  increasingly  making  use  of  formal  methods,  namely  specification  languages, 
automated  theorem  provers,  verification  tools  and  a  number  of  other  systems  based  on  formal  mathematical 
techniques. 

This  paper  focuses  on  the  issue  of  program  verification;  proving  that  programs  written  in  a  given 
language  conform  to  their  specifications,  ie  are  correct. 


1.1  Why  Program  Verification? 

Large  software  systems  are  now  widespread,  being  used  in  finance,  medicine,  defence,  uansport,  power 
generation  and  in  other  application  areas.  In  many  of  these  systems,  one  failure  could  be  disastrous, 
leading  to  loss  of  life,  damage  to  the  environment,  breaches  of  national  security  etc.  We  refer  to  these 
systems  generally  as  critical  systems,  because  failures  can  lead  to  critical  hazards  —  those  with  an 
unacceptable  risk.  In  safety-critical  software,  for  example,  attention  is  focused  on  the  possibility  of 
serious  injury  or  even  loss  of  life  if  the  software  fails. 

Si'ftware.  by  its  nature,  can  be  extremely  complex.  In  many  cases  it  is  not  possible  to  have  an  overall 
mental  grasp  of  what  a  piece  of  software  does.  Although  modern  software  engineering  stresses  the  use 
ot  s  iitable  prtigramming  languages  and  techniques,  errors  will  inevitably  occur  in  the  software.  Testing 
IS  tlie  iinie-hotioured  way  of  removing  these  errors.  Sometimes,  it  does  not  matter  if  software  has  errors 
—  tor  example,  the  software  used  to  write  this  paper  has  numerous  bugs,  but  none  of  these  prevent 
Useful  results  from  being  obtained. 

But  in  a  critical  system,  just  one  simple  error  somewhere  in  the  code  might  have  catastrophic  conse¬ 
quences.  In  the  USA,  the  FAA  and  NASA  have  established  a  requirement  of  less  than  10“ safety-critical 
failures  per  hour  throughout  a  ten  hour  flight  [1],  For  hardware  components,  it  is  possible  to  achieve  such 
low  failure  rates  by  using  highly  reliable  components  and  redundancy  in  the  design.  For  software,  the 
situation  is  different.  Current  software  testing  techniques  can  reduce  this  figure  to  perhaps  lO'^per  hour, 
resting  can  make  significant  contributions  to  the  assurance  of  safety:  however,  the  reliability  levels  ob¬ 
tained  by  testing  fall  far  short  of  the  levels  required  for  critical  applications.  In  any  case,  the  complexity 
,ind  logical  nature  of  software  means  that  a  pfobabili,stic  approach  is  of  doubtful  validity. 

Therefore,  in  such  cases,  testing  is  not  adequate  (Dijkstra’s  comment  that  testing  can  show  the  presence 
of  bugs,  but  never  their  absence,  is  well-known).  We  need  a  way  of  verifying  that  the  software  is  correct 
before  it  is  used. 

At  this  stage,  we  introduce  some  terminology.  Software  can  be  termed  correct  only  with  respect  to  a 
detailed  formal  specification  which  describes  exactly  what  the  program  is  required  to  do.  The  objective 
of  program  verification  is  to  prove  mathematically  that  every  execution  of  the  program  will  satisfy  the 
given  specifications. 

The  term  partial  correctness  is  used  to  describe  a  program  which  either  does  not  terminate,  or  else  is 
correct  with  respect  to  its  specifications;  the  term  total  correctness  is  used  to  describe  a  program  which 
is  correct,  and  also  terminates. 

In  practice,  it  is  also  desirable  that  the  formal  specifications  themselves  (which  can  be  complex  and 
subject  to  logical  and  other  errors)  be  proved  correct  with  respect  to  simpler,  more  abstract  specification. 
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In  this  case,  we  speak  of  design  verification.  Again,  this  specification  may  itself  need  to  be  verified 
against  an  even  simpler  and  yet  more  abstract  specification,  until  we  eventually  reach  the  fonnal  top- 
level  specification.  The  specifications  reflect  different  levels  of  detail  in  the  design.  Ultimately,  we  ne^ 
to  check  whether  the  specifications  capture  the  original  informal  user  requirements.  This  step  is  called 
validation.  The  issues  of  design  verification  and  validation  will  not  be  considered  further  in  this  paper. 

Henceforth,  we  shall  use  the  term  verification  as  a  shorthand  for  program  verification. 


1.2  Aim  of  the  Paper 

The  verification  of  a  program  is  a  difficult  task  —  much  harder  than  programming  itself.  It  is  an 
essentially  mathematical  task.  System  specifications  are  naturally  expressed  in  a  mathematical  notation, 
and  the  process  of  verification  uses  techniques  of  mathematical  proof. 

It  follows  that,  if  we  are  to  say  mathematically  that  a  program  behaves  correctly  with  respect  to  its 
specifications,  then  we  must  have  a  clear  mathematical  description  of  what  the  program  does.  In  other 
words,  the  semantics  of  the  language  needs  to  be  clearly  formulated  so  that  the  meaning  of  constructs 
in  the  language  is  well-understood. 

We  need  to  construct  a  mathematical  model  of  the  system  by  formulating  a  theory  based  on  certain  axioms, 
and  proving  theorems  from  these  axioms.  The  mathematician  may  be  content  with  —  and  convinced  by 
—  paper  and  pencil  proofs.  However,  mathematical  models  of  critical  systems  need  to  be  subjected  to 
a  greater  level  of  rigour.  In  such  cases  an  automated  reasoning  tool  can  help  us  formulate  the  theory, 
manage  the  proofs  of  key  results  and  avoid  logical  errors,  leading  to  increased  assurance  of  correctness. 

It  is  the  interaction  of  the  language  semantics  with  the  issue  of  program  verification  which  this  paper 
concentrates  on.  Our  aim  is  to  construct  a  program  verification  system  for  a  language  L,  which: 

1.  is  clearly  based  on  semantics  of  L; 

2.  is  easy  to  modify; 

3.  can  evaluate  programs  and  expressions  (i.e.  act  as  an  interpreter  if  required); 

4.  can  carry  out  non-trivial  reasoning  ^ut  programs; 

5.  can  prove  some  non-trivial  programs  correct; 

6.  compares  well  with  other  systems; 

7.  is  efficient,  easy  to  use; 

8.  is  applicable  to  concurrent  programming  languages;  and 

9.  can  help  assess  language  design  and  semantics. 

The  plan  of  this  paper  is  as  follows.  We  shall  fint  describe  in  Chapter  2  various  approaches  to 
programming  language  semantics.  In  Chapter  3,  because  of  its  importance  for  the  theorem  proving 
tools  we  use,  the  language  ML  will  be  described.  In  Chapter  4  we  give  an  overview  of  the  HOL  system, 
followed  by  some  examples  of  verification  for  a  small  language.  Chapters  6  and  7  deal  with  the  theorem 
prover  Isabelle  and  with  examples  of  verification.  Finally,  in  Ch^)ter  8  we  make  some  comments  on  the 
theorem  proven  used,  and  make  some  suggestions  f<»  fimher  work. 
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Chapter  2  PROGRAMMING  LANGUAGE  SEMANTICS 


2.1  Introduction 

There  are  three  eharacteristics  of  programming  languages  [2]: 

1.  syntax:  the  structure  and  appearance  of  legal  phrases  in  the  language; 

2.  semantics:  the  assignment  of  meanings  to  the  phrases;  and 

3.  pragmatics:  the  areas  of  application  for  the  language,  methods  of  implementation  etc. 

Of  these  three  aspects,  the  first  two  are  directly  relevant  for  program  verification.  The  specification  of 
language  syntax  is  by  now  well-understood,  and  Backus  Naur  form  (BNF)  is  routinely  used  to  describe 
syntax.  The  semantics  of  the  language  is  more  difficult  to  describe,  and  there  is  no  single  method  in 
widespread  use.  Language  .semantics  is  of  central  importance  for  program  verification.  We  must  have  a 
reliable  and  usable  definition  of  the  semantics  in  order  to  talk  about  program  correctness. 
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2.2  .Methods  for  semantics  specification 

There  are  at  least  four  general  methods  for  describing  the  semantics  of  a  language,  which  fefiect  the  rather 
different  ways  in  which  a  program  can  be  viewed,  ranging  from  highly  abstract  mathematical  constructs 
to  changes  in  the  physical  state  of  hardware  devices.  The  study  of  programming  language  semantics  is 
a  fascinating  and  rapidly  growing  area  of  modern  computer  science. 

The  method  of  denotational  semantics  maps  each  phrase  in  a  language  (and,  in  particular,  a  program) 
directly  to  its  meaning  (called  its  denotation),  which  is  a  mathematically  defined  object,  often  a  number 
or  a  function.  Thus  the  phrase  is  regarded  as  having  a  meaning  even  it  no  interpreter  or  compiler  for 
the  language  exists. 

The  method  of  operational  semantics,  sometimes  called  natural  semantics,  gives  the  meaning  of  a  program 
in  terms  ot  an  interpreter  for  the  language.  It  defines  a  program  in  the  language  in  terms  of  a  sequence 
of  interpreter  configurations.  The  semantics  is  given  as  a  number  of  inference  rules  which  describe  under 
what  conditions  a  language  consmict  will  evaluate  to  a  particular  value. 

In  the  method  of  axiomatic  semantics,  the  meaning  of  a  program  is  not  explicitly  given.  Rather,  logical 
propenies  about  language  constructs  are  defined,  and  a  number  of  axioms  and  inference  rules  describe 
under  what  conditions  an  assertion  about  a  construct  will  follow.  The  most  familiar  example  of  the 
■Lxiomatic  method  is  Hoare  logic,  which  capmres  assertions  about  the  partial  correctness  of  imperative 
languages. 

Finally,  an  approach  which  is  es.sentially  equivalent  to  the  denotational  description  is  the  method  of 
aliiehraic  semantics  [3].  In  this  case,  one  studies  many-sorted  algebras  and  functions  from  these  algebras 
to  possible  spaces  of  meanings.  A  familiar  analogy  in  mathematics  is  that  of  group  theory;  groups  may 
be  studied  as  abstract  objects,  and  the  various  representations  of  the  group  in  (say)  finite-dimensional 
vector  spaces  can  also  be  studied.  Although  a  most  interesting  area,  under  mvestigation  by  a  number  of 
theoretical  computer  scientists  (including  a  strong  group  in  France),  it  has  not  yet  been  applied  to  real 
programming  languages.  We  shall  not  be  examining  this  approach  further  in  this  paper. 

Although  these  various  methtxls  all  attack  the  problem  of  assigning  meaning  to  programs,  they  are  really 
complementary  rather  than  competing  methods.  Whichever  approach  one  chooses  depends  on  particular 
aspects  of  the  language  one  is  studying.  Broadly  speaking,  we  have  the  following  hierarchy  [2]; 

axiomatic  semantics  — >  denotational  semantics  — »  operational  semantics 

language  design  —  language  development  — >  language  implementation 
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2.3  Denotational  Semantics 

We  shall  now  give  an  overview  of  denotational  semantics  using  a  couple  of  examples.  The  subject  is  a 
large  one,  and  we  do  not  have  the  space  to  give  more  than  a  brief  description  here.  There  are  a  number  of 
textbooks  on  the  subject  Gordon  [4]  gives  an  elementary  introduction  which,  however,  glosses  over  the 
deeper  mathematical  ideas;  Sioy’s  book  [S]  is  an  excellent  account  of  the  subject  The  book  by  Schmidt 
[2]  is  perhaps  the  best  and  most  up-to-date,  while  the  review  article  by  Mosses  [61  is  excellent  notably 
for  his  attempt  to  standardise  the  notation.  These  last  two  accounts  contain  numerous  useful  references. 

Denotational  semantics  establishes  a  canonical  definition  for  a  language,  and  thereby  documents  the 
design  of  that  language.  It  also  establishes  a  standard  for  implementations  of  the  language.  Also,  and 
importantly  for  us,  a  denotational  semantics  definition  provides  a  basis  for  reasoning  about  the  correcmess 
of  programs,  either  directly,  or  else  indirectly,  by  means  of  derived  proof  rules. 

Eienotational  semantics,  by  its  nature,  is  built  on  a  number  of  mathematical  concepts  and  some  special 
notation.  These  will  be  introduced  as  needed. 


2.J.1  History 

The  systematic  study  of  denotational  semantics  was  begun  in  1964  [7]  by  Christopher  Sirachey  in  the 
Programming  Research  Group,  University  of  Oxford.  Strachey  was  using  the  type-free  lambda-calculus 
to  assign  meaning  to  programming  constructs.  In  the  words  of  Mosses  [6]: 

“By  1969,  Dana  Scott  [the  logician]  had  become  interested  in  Strachey’s  ideas.  In  an  exciting  collab¬ 
oration  with  Strachey,  Scott  first  convinced  Strachey  to  give  up  the  type-free  lambda  calculus;  then  he 
discovered  that  it  did  have  a  model  after  all.  Soon  after  that,  Scott  established  the  theory  of  semantic 
domains,  providing  adequate  foundations  for  the  semantic  descriptions  that  Strachey  had  been  writing.” 

Scott’s  contribution  was  to  put  the  entire  formalism  of  denotational  semantics  on  a  sound  mathematical 
footing,  using  the  theory  of  domains  to  make  legitimate  the  definitions  of  while  loops,  recursive  functions 
and  recursively  defined  domains.  Their  remarkable  collaboration  continued  unbl  Strachey’s  untimely 
death  in  1975. 


2.3.2  Syntax 

We  need  to  understand  programming  language  syntax  in  order  to  fonnalise  semantics  correctly.  Concrete 
syntax  regards  a  language  as  a  set  of  strings  over  some  alphabet,  while  abstract  syntax  regards  a  language 
as  a  set  of  derivation  trees.  Denotational  semantics  is  solely  concerned  with  abstract  syntax.  It  is  the  job 
of  a  parser  to  describe  how  to  get  fiom  the  concrete  to  the  abstract  syntax  (the  reverse  transformation 
is  called  unparsing,  or  pretty-printing).  The  concrete  syntax  is  obtainable  from  the  abstract  syntax  in  a 
well-defined  way,  and  is  not  important,  save  to  make  programs  more  readable  (we  shall  see  later  on  that 
this  i'  a  very  real  concern  in  modelling  semantics  in  HOL  and  Isabelle). 

It  will  be  useful  to  introduce  as  a  working  example  a  small  imperative  language  (essentially  the  language 
discussed  by  Schmidt)  which  we  shall  call  IMPl.  Its  abstract  syntax  is  given  below: 
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In  the  abtive,  tor  example,  the  notation  "e  :  Expression”  means  that  Expression  is  a  syntactic  Jomain. 
and  that  e  is  the  non-terminal  representing  an  arbitrary  element  of  that  domain  (this  is  a  set-theoretic 
view)  or.  if  we  prefer,  we  can  think  of  “e  :  Expression”  as  stating  that  e  is  an  arbitrary  element  of  type 
I  Expression  (a  type-theoretic  view).  The  latter  view  is  a  natural  one  when  we  use  a  typed  logic  such  as 

HOL  to  formulate  semantics,  as  we  shall  see.  (However,  we  must  be  careful  to  distinguish  types  in  the 
logic  from  types  In  the  language  being  studied,  if  any). 

The  syntttx  is  formulated  in  terms  of  a  context-free  grammar  (CFG).  The  BNF  rule  for  a  typical  expression 
e  says  that  an  expression  can  either  be  the  sum  of  two  other  expressions,  an  identifier,  or  a  number.  In  the 
I  grammar,  objects  such  as  Number  and  Identifier  have  no  BNF  rules  associated  with  them;  they  are  tokens. 

It  IS  well-known  that  certain  features  of  a  language  (such  as  typing  information  and  declarations  of 
variables  before  they  are  used),  cannot  be  handled  by  a  context-free  grammar;  these  are  context-sensitive 
features.  In  denotational  semantics,  it  turns  out  to  be  more  convenient  to  regard  such  features  not  as  part 
of  syntax,  but  as  part  of  the  .semantics,  called  static  semantics  because  it  only  depends  on  the  program 
text,  and  not  on  how  the  program  might  behave  at  run-time.  In  this  paper,  we  shall  only  be  concerned 
1  with  run-time  behaviour  {\.t.dyruimic  semantics). 


.VB,STR.\CT  SY.NTAX  OF  IMP  I 

[)  :  Proginm 
r  :  (-’oiiimand 
t-  .  Expression 
h  Booleanexpr 

I  ;  Kleiitifier 

II  :  Xuiiiber 

p  ;:=  c 

c  ;;=c^  ;  ci  |  if  then  Cj  else  Cj  ]  i  =e  |  diverge  (  skip  j  while  b  do  c 
e  ::=  ei  -(-  ej  I  i  |  n 
b  ei  =  e^  |  ->1)  |  true  |  false 


2.3J  Semantic  Algebras 

Denotational  semantics  is  built  on  domain  theory,  due  to  Scott.  The  fundamental  concept  in  domain 
theory  is  that  of  a  semantic  algebra,  which  consists  of  an  underlying  set  (called  a  semantic  domain). 
along  with  a  number  of  operations  on  the  domain.  A  basic  example  of  a  semantic  algebra  is  the  set 
Nat  of  natural  numbers,  along  with  the  operations  plus,  minus  and  times.  Certain  special  domains  are 
necessary  to  allow  the  modelling  of  .such  things  as  while  loops  and  recursive  data  types. 

From  primitive  domains,  a  number  of  compound  domains  can  be  obtained  by  means  of  domain  consfruc- 
tors.  These  are  (if  A  and  B  are  domains) 

1.  Product  domain  A  x  B 

2.  Sum  domain  A  -f  B  (also  known  as  the  disjoint  union) 

3.  Function  domain  A  —  B 

4.  Lifted  domain:  Aj. 
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The  fint  three  constructions  are  well-known.  The  fourth  one  adds  a  special  element  called  ±  (read  "bot¬ 
tom ")  which  denotes  nonterminadon  or  undefined.  It  is  needed  to  model  nonterminating  computations 
and  partial  functions.  A  function  f:  —  Bs_  is  called  strict  if  /(±)  =  J..  If  Ax.a  is  some  function  on 

A,  then  we  use  the  notation  Ax, a  to  denote  the  extension  to  a  strict  function  on  Aj.. 

Recursively  defined  domains,  such  as 


Value  =  Number  -1-  (Value  —  Value) 


need  special  handling.  The  central  role  of  domain  theory  is  to  make  sense  of  such  equations.  It  turns  out 
that  the  above  equation  has  a  solution  provided  thm  the  functions  in  the  domain  A  — >  B  are  restricted  to 
be  those  which  are  continuous  with  respect  to  a  certain  topology  (called  the  Scott  topology)  on  A  and 
B.  Imposing  restrictions  onto  a  set  in  order  to  make  rigorous  concepts  which  already  seem  intuitively 
clear  is  a  well-known  technique  in  mathematics  (examples  are  the  theory  of  distributions,  or  generalised 
functions,  and  the  theory  of  quantum  mechanical  operators)  However,  the  technique  is  perhaps  less 
familiar  in  computer  science. 

We  now  return  to  our  example  IMPt.  Imperative  languages  use  a  special  data  structure  called  a  store, 
which  exists  independently  of  any  program  in  the  language.  Certain  constructs  can  access  and  update 
the  store.  In  IMPl,  we  can  think  of  the  store  as  computer  memory. 

The  semantic  algebras  for  IMPl  are  the  basic  domains  in  which  the  meaning  of  our  language  constructs 
will  be  defined.  We  shall  model  the  store  as  the  domain  of  functions  firom  identifiers  to  values.  In  the 
table  below,  b  x  □  y  is  a  shorthand  for  "if  b  then  x  else  y" 
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SEMANTIC  ALGEBRAS  FOR  IMPl 
Truth  values 

Domain  :  Tr  =  {true,  false} 

Operati' ms  : 
not  ;  Tr  —  Tr 

Ulentifiers 
Domain  :  Ide 

Natural  Numbers 
Domain  :  Nat 
Operations  : 
plus  :  Nat  X  Nat  —  Nat 
eipials  Nat  x  Nat  —  Nat 

Store 

Domain  Store  =  Ide  —  Nat 
0|ierations  , 
newsiore  Store 
iiew.store  =  Ai.O 

ai  Tess  Me  —  Store  —  Nat 

atU'ess  IS  =  St  I ) 

update  Ide  —  Nat  —  Store  —  Store 
update  1  n  s  =  ( Aj.j  =  i  =>  n  □  s(j)) 


2.3.4  Semantics 

Die  final  sfep  is  to  assign  a  meaning  to  each  phrase  in  the  language  by  giving  a  valuation  (or  meaning) 
iimction  from  the  phrase  in  terms  of  elements  and  operations  of  the  semantic  domains.  The  definition  is 
an  inductive  one,  guided  by  the  abstract  syntax  of  the  language.  The  key  property  is  that  the  meaning  of  a 
phrase  is  defined  solely  in  terms  of  the  meaning  of  its  proper  subphrases  (this  is  called  compositionality). 
For  example,  the  meaning  of  the  phrase  “if  b  then  ei  else  e:"  will  depend  on  the  meanings  of  the  boolean 
expression  b,  and  the  other  expressions  ei  and  ej.  There  are  a  number  of  pnmitive  phrases,  such  as 
assignment,  which  do  not  depend  on  any  other  phrases. 

In  the  ca.se  of  IMPl,  it  is  natural  to  picture  a  command  as  an  operation  taking  a  given  store  to  a  new 
store.  Thus  its  meaning  will  be  given  by  a  function  of  the  following  type: 

C  :  Command  — ►  Store j.  — ►  Storex 

The  Store  domain  is  lifted  because  the  action  on  the  store  may  not  terminate.  It  is  natural  to  take  C  to 
be  a  strict  function  on  Storex,  i.e.  we  cannot  recover  from  an  nonrecoverable  situation. 

1  The  semantics  for  IMPl  is  given  below  —  omitting,  for  the  moment,  the  while  construct,  which  wilt 

be  discussed  later. 
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SEMANTICS  FOR  IMPl 
P  :  Program  — *  Nat  — •  Nat^ 

P[c]  =  An. let  s  =  (update  input  n  newstore)  in  let  s'  =  C[c]s  in  (access  output  s') 

C  :  Command  — •  Store  —  Store 
C[ci;c2]  =  As.C(ci](C[c2]s) 

C[if  b  then  ci  else  C2]  =  As.B[b]s  ^  C[ci]s  □  C[c2]s 
C[i  :=  e]  =  As. update  i  E[e]s  s 
C[diverge]  =  As.± 

E  :  Expression  —  Store  —  Nat 
E[ei  +  e2]  =  As.E[ei]s  plus  E[e2]s 
E[i]  =  As. access  i  s 
E[n]  =  As.n 

B  :  Booleanexpr  —  Store  —  Tr 
B[ei  =  e2]  =  As.E[ei]s  equals  E[e2]s 
B[-b]  =  As.-(B[b]s) 

B[true]  =  true 
B[false]  =  false 


The  above  valuation  functions  are  what  we  would  expect.  The  semanuc  functions  have  as  their  arguments 
phrases  of  the  language,  enclosed  in  square  brackets  for  readability.  Purely  for  convenience,  the  equation 
for  P  says  that  the  meaning  of  a  program  is  obtained  by  taking  an  input  number,  associating  it  with  the 
special  identifier  ’input',  evaluating  the  body  of  the  program,  and  then  extracting  the  answer  from  the 
identifier  'output'.  Note  that  an  expression  does  not  have  side-effects  in  its  evaluation;  it  may  need  to 
consult  the  store  to  be  evaluated,  but  will  never  change  it 

As  a  simple  example  of  working  with  denotational  semantics  we  have: 

Pfoutput  :=  1;  if  input  =  0  then  diverge;  output  :=  3]  =  An  n  equals  0  ±  □  3 

The  proof  is  straightforward  (it  is  treated  in  detail  in  [2]).  For  this  program,  if  the  input  is  0,  the  answer 
is  undefined;  in  all  other  cases  the  answer  is  3. 

Once  we  have  captured  the  denotational  semantics  of  a  language,  there  is  an  immediate  notion  of 
equivalence  of  expressions  and  commands  (and  hence  programs).  We  define: 

ei  ss  62  o  E[ei]  =  Efe:] 

Cl  sjs  C2  C[ci]  =  C(c2] 

This  is  an  important  notion:  in  proving  the  correctness  of  a  program  p  we  may  wish  first  to  apply  a 
transformation  T  in  order  to  simplify  iL  If  p  »  T(p),  then  the  correctness  (or  otherwise)  of  p  will  be 
preserved  by  the  transformation.  Here  are  some  examples  of  equivalences  (where  c,  Ci ,  C2  are  arbitrary 
commands  and  b  is  an  arbitrary  boolean  expression): 

Cl  -h  62  «  ej  -E  ej 
(  c;  skip)  V  (skip;  c)  as  c 
if  b  then  ci  else  C2  «  if  -•b  then  C2  else  ci 
X  ;=  0;  y  ;=  x  +  I  w  y  ;=  1;  x  ;=  0 
The  proofs  are  again  straightforward. 
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2.3.5  Recursively  Defined  Functions 

As  we  remarked  earlier,  certain  types  of  language  construct  require  more  formal  machinery  to  capture 
their  meaning  in  Jenotational  semantics. 

Once  such  problematic  constnict  is  the  while  loop,  which  we  omitted  from  our  earlier  discussion  of  the 
language  I.\1PI.  We  could  attempt  to  define  its  meaning  as  follows: 


('[whiie  h  do  c]  As.B[b]s  =>  C[while  b  do  c](C[c]s)  □  s 


This  certainly  capmres  our  intuition  about  what  a  while-loop  should  do,  but  it  is,  unfortunately  violating 
the  requirement  that  the  meaning  of  a  program  phrase  must  be  defined  in  terms  of  its  proper  subphrases. 

The  theory  of  domains  provides  us  with  a  rigorous  way  of  capmring  the  semantics  of  while,  along  with 
other  rectirsive  objects.  Essentially,  we  need  to  make  formal  the  meaning  of  a  recursive  specification. 
Space  does  not  permit  us  to  do  more  than  summarise  this  theory,  but  here  are  some  key  results.  For 
more  details,  consult  the  book  by  Schmidt  [2]. 

A  partial  ordering  on  a  set  D  is  a  relation  C  which  is: 

,1.  reflexive:  Va  €  D,  a  C  a: 

b.  antisymmetric:  Va.  b  €  D.  a  C  b  and  b  C  a  D  a  =  b;  and 

c.  transitive:  Va,  b,  c  6  D.  a  C  b  and  b  C  c  D  a  C  c 

A  iea.a  element  of  D  with  respect  to  this  ordering  is  an  element  ±  such  that  Va  €  D,  J.  C  a.  If  X  is  a 
Mibset  of  D.  then  the  least  upper  hound,  written  denotes  the  element  of  D  (if  it  exists)  such  that: 

.1,  V.\  e  .\.  .X  C  IJ  .\  and 

b.  Vd  €  D,  if  Vx  €  .X.  X  C  d  then  |J  .X  C  d 

non-empty  subset  X  of  D  is  called  a  cfiam  if.  Va,  b  €  X  either  a  C  b  or  b  C  a.  Finally  D  is  called  a 
doiiuiin  if  D  has  a  least  element  J.  and  every  chain  has  a  least  upper  bound. 

Suppose  that  A  and  B  are  sets  with  partial  orderings.  A  function  f  :  A  —  B  is  called  monotonic 
if  Vx  y  G  A,  f(a)  C  f(b).  The  function  f  is  called  continuous  if  it  is  monotonic  and,  furthermore, 
for  r-very  cliniii  X  C  A,  f(lJX)  C  (J  {f(x)  |  x  G  -X}.  If  F:  D  —  D  is  continuous,  then  i  fixed  point  of  F 
IS  an  clement  d  of  D  such  that  F(d)  =  d.  It  is  called  the  least  fixed  point  of  f  if.  Ve  G  D,  F{e)  =  e  D  d  C  e. 

Hie  key  result  of  domain  theory  is  the  following: 

Theonem:  If  D  is  a  domain,  then  every  funciion  F  :  D  —  D  has  a  least  fixed  point,  given  by: 


fixF  =  U{F‘(X)|i>0} 


We  then  take  the  meaning  of  a  recursive  specification  f  =  F  (f)  to  be  fix  F. 

It  can  be  shown  that  the  domain  constructors  described  earlier  all  construct  new  domains  from  given 
domains  (which  justifies  their  name).  A  primitive  domain  such  as  Natx  is  given  the  discrete  partial 
ordering:  a  C  b  a  =  b  or  a  =  J.  (such  domains  are  called  flat). 

Now  we  are  in  a  position  to  define  the  meaning  of  a  while  loop  as  follows: 


f 


C[while  b  do  c]  =  fix  (Af,2s.B[b]s  =>  f(C(c|s)  □  s  ) 
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To  complete  the  discussion  of  fixed  points,  we  note  that,  for  certain  kinds  of  predicates  (called  inclusive 
predicates),  we  have  an  important  induction  principle,  known  as  fixed-point  induction.  For  such  a 
predicate  P  on  a  domain  D,  we  have  the  inference  rule: 

P(l)  Vd  g  D,  P(d)  DP(F(d)) 

P(fix  F) 

This  result  is  very  important  for  reasoning  about  fixed  points  in  theorem  provers  such  as  LCF. 

2.3.6  Limitations 

By  now,  the  methods  for  giving  denotational  senuintics  for  sequential  programming  languages  are 
well-understood:  all  the  constructs  used  in  such  languages  have  given  well-defined  mathematical 
formulations.  This  is  true  of  blocks,  jumps,  procedures  and  functions  and  so  on.  However,  the  method 
has  its  limitations  [6]. 

The  extension  of  denotational  semantics  to  cover  parallel  languages  is  not  straightforward.  The  problem 
is  that  denotational  semantics  makes  heavy  use  of  functions,  whereas  the  essential  property  of  parallel 
programs  is  non-determinism.  In  contrast,  operational  semantics  (see  below)  extends  quite  neatly  to 
cover  the  case  of  parallel  languages,  and  is,  for  example,  the  standard  way  of  formulating  Robin  Milner’s 
Calculus  of  Communicating  Systems. 

Also,  the  method  does  not  scale  up  well  to  real  programming  languages  —  whose  domains  can  be 
extremely  complex  —  and  it  is  fair  to  say  that  denotational  semantics  definitions  have  not  really  ejected 
the  mainstream  development  of  languages  such  as  Ada  [8].  Denotational  semantics  definitions  are  also 
very  hard  to  read,  and  make  little  sense  to  the  non-expert 

Another  issue  is  that  it  is  not  possible  to  reuse  parts  of  the  description  of  one  language  in  another 
language  (in  other  words,  denotational  semantics  has  no  construction  analogous  to  that  of  modules  in 
software  engineering). 


2.4  Operational  Semantics 

There  is  today  a  good  deal  of  interest  in  the  natural  or  operational  style  of  semantics,  which  grew  out  of 
the  work  of  Gordon  Plotkin  [9].  His  aim  was  to  formalise  language  semantics  in  a  natural  way,  in  terms 
of  transition  systems,  without  being  too  worried  about  mathematical  rigour.  The  method  has  found  favour 
among  those  who  wish  to  study  real  languages  without  wanting  to  use  a  full  denotational  semantics.  In 
fact,  the  definition  of  Standard  ML  is  given  in  terms  of  a  number  of  transition  rules. 

An  operational  semantics  is  given  by  defining  a  tranution  system,  which  we  define  to  be  a  pair  (F,  =>), 
where  F  is  a  set  of  configurations,  and  =»  is  a  relation  on  F.  with  the  interpretation  that  71  ^  72  means 
that  7i  evaluates  to  72.  Many  systems  actually  fall  into  the  category  of  transition  system,  but  we  are  most 
interested  in  the  case  of  language  semantics,  where  a  number  of  inference  rules  capture  the  meaning  of 
the  language. 

Operational  semantics  has  the  advantage  that  it  is  an  easier  formalism  to  understand  than  denotational 
semantics.  Also,  as  mentioned  above,  it  is  better  able  to  cope  with  the  treatment  of  non-deterministic 
languages,  where  meaning  is  captured  by  relations  rather  than  functions.  The  main  disadvantage  is  that  it 
is  tied  to  the  way  an  interpreter  will  evaluate  phrases  in  the  language,  and  so  it  is  not  a  good  formalism 
for  reasoning  about  termination,  or  loops  which  may  iterate  an  aihicraiy  number  of  times  depending  on 
the  input 

Our  discussion  of  operational  semantics  draws  on  the  lecture  notes  of  Milner  [10] 

2.4.1  Semantics  of  FUNCl 

As  an  example,  we  shall  consider  a  very  simple  language  FUNCl,  with  simple  expressions  and  a 
mechanism  for  local  scoping,  which  later  will  be  extended  to  a  functional  langu^ 
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SYNTAX  OF  FUNCl 

t-XpivSilOtl 
'1  ilt'i'laiatioii 
X  :  I'lf'nritiai' 

11  iiiiiiilifr 

t*  X  I  11  I  ei  +  ej  |  let  <1  in  e 

(1  :;=  X  =  e  I  (1,  ;  d-., 


Phrases  in  this  language  are  evaluated  in  the  context  of  an  environment,  which  records  the  current 
bindings  of  identifiers  to  their  values  (in  this  case  numbers).  We  shall  regard  an  environment  as  a  set 
of  pairs,  as  follows: 

E  =  {(xi.ni),,  ...(Xk.ni,)} 

Our  uaiisition  system  relation  has  the  form: 

I 

I  Environment  1-  phrase  ^  result 

'  in  which  the  result  is  a  number  if  the  phrase  is  an  expression,  and  is  an  environment  if  the  phrase  is 

I  a  declaration.  Below  are  given  the  inference  rules  for  the  operational  semantics  of  FUNCl.  We  use 

t  the  notation  EiEi  to  denote  the  new  environment  obtained  from  Ei  by  overwriting  its  bindings  with 

those  of  E;: 

OPEP.ATIONAL  SEMANTK'.S  FOR  FUNCl 

1 

Ex[irHs.siotis 

t  E  ^  x  =>  II  if(.x,  n)eE 

E  r  11  =>  n 

E  b  =>  111  E  1-  I'n  =>  ut  11  =  111  +  ii-.> 

E  b  Pi  +  e;.  n 

Eb.|=»E'  EE'be=»n 
E  b  let  d  in  e  ::*•  n 

Declarations  : 

E  b  e  ^  n 

E  b  X  =  e  =>  {(x,  n)} 

I  E  b  ill  ^  El  EEi  b  d2  =>  Ea 

E  b  di  ;  dj  ^  E1E2 


I 
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As  examples,  we  have; 

E  h  let  X  =  5;  y  =  10  in  X  +  y  =>  15 
E  K  let  y  =  3  in  let  X  =  y  +  1  in  let  y  =  20  in  X  ^4 

The  second  example  illustrates  the  fact  that  we  have  static  binding:  x  uses  the  value  of  y  at  definition- 
time,  not  at  call-time. 

A  formal  proof  of  these  examples  uses  the  inference  rules  for  the  semantics  to  work  backwards  from 
what  it  is  required  to  prove  (the  “goal”),  constructing  a  proof  tree  whose  nodes  are  trivially  true. 

There  is  a  natural  notion  of  equivalence  with  respect  to  the  semantics  for  the  language  FUNCl.  We 
define  equivalence  of  expressions  and  declarations  as  follows: 

ei  ««  62  =  VE,  n:  EI-ei=>noEI“e2s>n 
di  w  dj  =  VE,  E'  :  E  h  di  =>  E'  O  E  I-  d2  =>  E' 

For  example,  it  is  easy  to  show  that: 


61  -1-62  is  62  -t-  61 

let  X  =  I  in  X  -1-  3  ss  let  y  =  2  in  y  -I- 1 
x  =  7;  y  =  9ssy  =  9;  x  =  7 


2.4.2  Semantics  of  FUNC2 

Now  let  us  extend  to  the  language  FUNCl  to  a  more  interesting  and  useful  language,  called  FUNC2.  It 
is  a  functioned  language:  functions  are  allowed  to  be  values,  and  can  be  passed  as  arguments  to  other 
functions.  We  shall  add  the  following  new  expressions:  conditional  expressions,  pairing  ei,  e2,  function 
application  et  (ej)  and  lambda-expressions  Ax.e.  We  have  also  included  parallel  declarations,  with  the 
construct  “and”.  Here  is  the  syntax  of  FUNC2: 

SYN'TA.X  OF  FUNC2 

e  :  expression 
d  :  declaration 
X  :  identifier 

c:  constant  =  number -I- {tt,  ff} -I- x  } 
e  .:=  X  1  C  I  61  ,62  I  61(62) 

I  if  60  then  6]  else  62  |  Ax.e  |  let  d  in  e 
d  ::=  X  =  e  |  di  ;  d2  |  di  and  d2 


An  environment  will  still  associate  identifiers  with  values;  however,  this  time  the  set  of  values  is  defined 
as  follows; 

•  every  constant  is  a  value; 

•  if  V]  and  V2  are  values,  then  V|,  V2  is  a  value;  and 

•  if  E  is  an  environment,  x  an  identifier  and  e  an  expression,  then  the  closure  <x,e,E>  is  also 
a  value. 

Function  closures  (or  function  values)  contain  all  the  information  necessary  to  evaluate  a  function,  we 
evaluate  e  (the  function  body)  in  the  environment  E  extended  by  associating  the  actual  parameter  value 
with  the  formal  parameter  x.  Closures  are  needed  to  avoid  inconsistencies  due  to  the  use  of  the  same 
identifier  as  both  a  bound  and  a  free  variable  (well-known  as  the  “funarg  problem”  in  LISP). 

Now  if  we  wanted  to  make  rigorous  sense  of  such  a  reciosively  defined  set  we  would,  of  course,  require 
the  machinery  of  domain  theory.  Thus  the  denotadonal  semantics  for  this  language  needs  some  special 
•  care.  However,  the  operational  semantics  is  not  difficult  to  formulate,  and  is  given  below: 
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OPERATION  AL  SEMANTICS  FOR  FUN'C2 
Expressions  : 

E  r  X  =>  V  iHx.  v)  e  E 
E  r  (■  =»•  r 

E  H  e;  =>  E  h  e;  Vt 
E  1-  ei.e^  Vi,  Vj 

E  r  e,  =>(x.e.  E')  EHe:;=>v  E'{(x.  v)}  h  e  =>  v' 
E  H  e[(e-_,)  =>  v' 

E  i-  e^  =>  (■  E  I-  ej  =?•  V  ;ipply(c,  v)  =  v' 

E  H  ei(e..)  =>  v' 

E  P  eg  true  E  l~  ei  =>  v 
E  p  if  e;i  then  ei  else  e-_,  ^  V 

E  p  eii  =>  false  E  p  e'_,  V 
E  P  if  e,,  then  ei  else  e^  ^  v 

E  Ax  e  (x,  e.  E) 

E  -  .1  E'  EE'  P  e  ^  V 
E  P  let  (1  m  e  =>  V 

Df-ilarntions 

E  P  e  ^  n 

E  P  X  =  e  =>  {(x,  n) } 

E  P  til  =>  El  EEi  P  'It  =>  Et 
E  P  ill  ;  ‘l’.>  ^  El Et 

E  P  (It  =>  El  E  P  'It  E2 
E  P  ill  ‘■'•■'‘I  'I2  ^  E1E2 


Note  that,  for  constants  such  as  +  which  happen  to  be  operations,  we  assume  that  the  semantic  algebras 
support  a  function  apply,  which  evaluates  its  application  to  arguments,  for  example  apply  [+.  (3,6)>>9. 
Also  note  that  there  are  two  rules  for  function  ap^icatlon,  according  as  the  operator  ei  of  the  application 
evaluates  to  a  closure  or  a  constant  value. 
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2.4.3  Semantics  of  FUNC3 

The  next  stage  is  to  extend  FUNC2  to  allow  for  recursively  defined  functions  in  the  language.  The 
extension  to  the  syntax  is  simply  to  allow  a  declaration  to  be  qualified  by  the  word  “rec”.  So  we  extend 
the  syntax  of  declarations  to  be: 


d  ::=  X  =  e  I  di  ;  d2  I  di  and  dj  |  rec  d 


This  will  allow  the  local  declaration  of  mutually  recursive  functions,  for  example: 

let  rec  (fi  =  Axi.ei  and  fj  =  Ax2.ej)  in  e 
in  which,  typically,  both  Ci  and  e:  might  contain  applications  of  ft  or  fz. 

Milner  [10]  gives  a  careful  discussion  of  how  the  operational  semantics  needs  to  be  modified  to  allow 
for  recursion.  We  shall  just  give  the  inference  rules  which  need  to  be  changed. 

Firstly,  we  need  to  extend  the  notion  of  function  closure  to  have  the  form  <x,e,Ef  >,  in  which  the  new 
fourth  component  is  an  environment  specifying  the  function  identifiers  which  must  be  treated  recursively 
when  we  evaluate  the  body  e  of  the  closure.  We  modify  the  rule  for  lambda-expressions  as  follows: 


E  H  Ax  e  =>  (x,  e,  E,  0) 


The  semantics  of  recursive  declarations  requires  the  key  notion  of  unfolding  an  environment,  defined  as 
follows,  if  E  is  an  environment,  then  whenever  E  contains  a  member 

(f,.^x,.e|,E,,E'^) 

then  UNFOLD  E  will  contain  instead  the  member 


(f,,(x,,e,,E,.E)) 


Now  we  can  give  the  rules  for  recunive  declarations  and  function  applications; 


E  h  d  =>  E' 

E  h  rec  d  =>  UNFOLD  E' 

Ephei  =»(x.e,E.E0  Ep  1- e2  =»  v  E(UNFOLD  E'){(x.  v)}  h  e  ^  v' 
Ep  H  ei(e2)  =»  v' 


We  shall  meet  the  languages  FUNCi,  FUNC2  and  FUNC3  again  later  on  in  Chapter  6,  where  we  set  up 
proof  procedures  for  reasoning  about  these  languages. 
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2.4.4  Semantics  of  IMPl 

It  IS  nut  hard  to  give  an  operational  semantics  for  the  language  IMPl  (whose  denotational  semantics  was 
given  earlier).  This  language  is  essentially  that  discussed  in  Milner’s  notes  [10],  It  has  also  been  studied 
by  Rachel  Roxas  and  Malcom  Newey  [11].  We  shall  not  give  its  semantics  in  full  here. 

Phra.se  evaluation  is  now  written  as  follows; 


fiivirorimerit  h  expression,  memoryi  ^  value, memory j 
environment  h  program,  memoryi  ^  memory2 


where  we  have  allowed  for  expression  evaluation  to  have  side-effects  and  change  the  memory  (for  the 
simplest  imperative  langauges  there  will  be  no  side-effects).  In  general,  there  is  also  an  environment  to 
allow  local  declarations,  as  for  our  functional  languages. 

Omitting  environments  for  now.  we  give  just  the  rules  for  assignment  and  while  loops: 


M  n.  M' 

.X  =  f*.  .\I  ^  iip(late(x.  n,  .\I') 

h.  M  =>  triie  .M'  |..  M' =>  .M"  while  b  .lo  p,  M"  =>  NT" 
while  h  do  p,  .\I  NT" 

1.,  M  =>  false.  .\I' 
while  1)  'lo  p,  .\I  =>  M' 


It  IS  not  diiticult  to  formulate  operational  semantics  for  the  other  constructs  found  in  imperative  languages 
I  procedure  calls,  jumps  etc),  but  we  shall  not  do  this  here. 


2.5  Axiomatic  Semantics 

Tlie  key  ideas  in  axiomatic  semantics  were  put  forward  in  1969  by  C  A  R  Hoare  [12]  in  a  paper  describing 
a  logic  for  capturing  assertions  about  a  small  imperative  language.  This  paper  had  a  major  impact,  and 
has  the  distinction  of  being  one  of  the  most  widely  cited  papers  in  computer  science.  There  has  been 
tremendous  activity  in  the  area  over  the  last  twenty  years,  as  witnessed  by  the  extensive  review  of  the 
subject  by  [13].  We  shall  give  a  brief  discussion,  following  Schmidt  [2], 

In  Hoare  logic  we  deal  with  partial  correctness  assertions  of  the  form  [P]  c  (Q).  which  specify  the 
behaviour  of  some  command  c  in  terms  of  predicates  P  and  Q,  which  are  functions  of  program  variables. 
Informally,  the  assertion  means  that  “if  P  is  true  in  some  state,  and  c  is  then  executed  and  terminates, 
then  Q  is  true  in  the  resulting  state”.  In  the  language  of  denotational  semantics,  such  an  assertion  reads: 


{P}c{Q}  =  Vs  €  Store.  B[P)s  A  -(C[c]s  =  ±)  3  B[Q](C[c]s) 


Some  examples  of  the  Hoare  rules  for  assignments,  sequencing  and  while  loops  are  given  below; 
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The  point  we  want  to  make  here  is  that  these  rules  can  be  shown  to  follow  from  the  denotational 
semantics  of  the  language  [2]. 

The  Hoare  rules  are  very  popular  in  program  verification,  and  many  treatments  of  the  subject  take  these 
rules  as  their  starting  point  However,  the  Hoare  rules  will  not  be  used  further  in  this  paper. 
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Chapter  3  INTRODUCTION  TO  ML 


In  tlii.s  chapter  we  shall  give  a  brief  overview  of  the  programming  language  ML  (ML  stands  for  Meta- 
Langiiage),  on  which  both  the  HOL  system  and  Isabelle  are  built.  ML  was  originally  developed  during 
work  on  the  early  theorem  prover  LCF  (LCF  stands  for  Logic  for  Computable  Functions),  which  was 
developed  by  Robin  Milner  and  collaborators  in  the  early  1970’s  [14], 

ML  has  now  become  an  important  programming  language  in  its  own  right.  Even  during  its  early  stages, 
the  language  featured  higher  order  functions,  along  with  a  robust  type  system  with  an  method  for  type 
inferencing,  and  had  an  exception  raising  mechanism  to  facilitate  the  definition  of  proof  tactics.  ML  was 
redesigned  to  incorporate  new  ideas  from  the  work  of  Burstall’s  group  on  HOPE  and  CLEAR  .  such  as 
pattern  matching  and  the  mixlular  construction  of  specihcaiions  using  signatures  in  the  interfaces.  Most 
recently,  a  major  enhancement  to  ML  has  been  that  of  modules,  due  to  MacQueen. 

The  agreed  standard  for  the  language  is  called  Standard  ML  (SML),  and  its  definition  is  given  in  [15]. 
A  readable,  but  low-level,  intrtxluction  to  the  language  is  the  book  by  Wikstrom  [16].  Another  readable 
summary  of  ML  is  the  manual  for  the  version  under  development  by  Malcolm  Newey  and  collaborators 
at  the  Australian  National  University[17].  However,  since  we  are  discussing  the  HOL  system  first,  the 
examples  in  this  chapter  will  be  for  the  slightly  different  dialect  of  the  language  on  which  HOL  is  built. 
(The  theorem  prover  Isabelle  is  built  on  SML).  We  do  this  for  convenience:  the  differences  are  not 
significant  for  the  examples  we  wLsh  to  give. 


3.1  Features  of  ML 

.ML  IS  a  modern  functional  programming  language,  with  a  number  of  powerful  features  which  follow 
modern  software  engineering  principles.  In  fact  NIL  is  the  paradigm  for  a  functional  language  which 
we  have  in  mind  for  our  e.xperiments  on  the  verification  of  programs  written  in  functional  languages. 
Here  are  the  highlights  of  ML. 

□  It  IS  a  functional  language  —  functions  are  first-class  objects  and  can  be  passed  as  arguments 
to  other  functions,  or  returned  as  values. 

□  It  IS  statically-scoped:  identifiers  are  associated  with  values  according  to  where  they  appear 
in  the  program  text  (and  not  on  the  run-time  behaviour  of  the  program).  This  is  safer  than 
dynamic  scoping  (as  in  LISP). 

□  It  IS  a  strongly  typed  language  —  every  ML  expression  has  a  statically-determined  type.  The 
type  of  an  expression  can  usually  be  inferred  automatically,  by  an  algorithm  due  to  Milner. 
This  catches  many  trivial  errors  at  compile-time,  and  promotes  good  programming  practice. 

□  It  is  polymorphic  —  type  expressions  may  contain  type  variables,  to  allow  for  functions  to 
be  defined  on  a  class  of  arguments  of  different  types. 

□  It  has  facilities  for  abstraction  —  the  user  can  define  new  abstract  data  types  and  hide  the 
details  of  their  implementation  from  functions  which  make  use  of  them. 

□  It  has  a  modules  facility,  allowing  the  grouping  of  large  ML  programs  into  separate  units 
which  can  be  separately  compiled. 

□  It  has  an  exception  trap  mechanism,  to  allow  the  uniform  handling  of  user  and  system- 
generated  exceptions. 

□  It  has  a  rigorous  semantics  —  the  language  definition  of  SML  [15]  is  expressed  in  terms  of 
operational  semantics,  so  that  implementors  and  others  know  what  is  required.  There  is  also 
an  (unpublished)  denotational  semantics  for  the  language,  due  to  Gordon  and  Milner. 


3.2  Syntax 

In  this  section  we  shall  summari.se  the  syntax  of  ML.  concentrating  on  the  bare  essentials.  The  following 
table  shows  which  variables  are  used  to  range  over  the  various  semantic  domains  of  ML. 
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Table  1  Notation  for  Semantic  Domains 


Variable 

Ranges  over 

var 

variables 

con 

constructors 

constexp 

constant  expressions 

d 

declarations 

b 

bindings 

P 

patterns 

e 

expressions 

A  simplified  syntax  of  ML,  in  which  we  omit  types,  precedence  information,  constructs  which  are 
equivalent  to  others,  and  certain  exotic  forms  of  exceptions  can  be  summarised  as  follows: 

d  ::=  let  b  |  letref  b  |  letrec  b 

b  p  =  e  I  var  pi  p2  ...  pn  =  e  |  bj  and  b2  and  ...  and  bn 
p  i  constexp  I  var  I  con  p  I  P1P2  I  Pi ,  P2  I  Q  I  [Pi;  Pn] 
e  ::=  constexp  |  var  |  con  |  ei  62 

I  px  e  I  ei  ix  62  I  p  :=  6  I  failwith  e 
( if  ei  then  62  {else  ea} 

I  ei  ■’  62 

I  while  ei  do  62 

|ei;...;en  |  Q  |(ei;...e„]  |  d  in  e 
I  \pi  P2  ■  •  Pn-e 

I  fun  Pi  .  ei  I  P2  .  62  I  ...  I  Pn  .  Cn 


3.3  Examples 

Rather  than  give  a  formal  definition  of  the  semantics  of  ML,  we  shall  be  content  to  explain  the  language 
by  means  of  a  number  of  examples. 

ML  constructs  are  evaluated  in  the  context  of  an  environment  and  a  store  (these  concepts  have  already 
been  discussed  in  2).  The  environment  holds  current  bindings.  It  specifies  what  the  variables  and 
constructors  in  use  denote  —  they  may  be  bound  either  to  values  or  locations.  The  store  specifies  the 
contents  of  locations  (which  must  be  values). 

Evaluation  of  a  declaration  d  changes  the  bindings  in  the  environment  of  the  identifiers  declared  in  d. 
Evaluation  of  an  expression  yields  a  value.  Any  assignment  done  during  an  evaluation  changes  the  store 
(such  changes  are  called  side-effects). 

Expressions  and  patterns  may  optionally  be  given  types  (for  example  x:  int),  which  forces  the  type- 
checker  to  assign  an  instance  of  the  asserted  type  to  this  construct 

We  shall  illustrate  the  various  constructs  in  ML  by  means  of  some  simple  sessions  with  the  HOL  system. 
In  these  interactions,  #  is  the  HOL  prompt  and  the  user  enters  ML  phrases  followed  by  two  semi-colons. 
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3.3.1  Expressions 

Expressions  can  take  a  number  of  forms.  A  simple  example  is: 


Tlie  value  of  the  expression  (12)  is  returned,  along  with  its  type  (int).  Here  are  some  other  examples: 


3.3.2  Declarations 

The  declaration  let  x  =  e  evaluates  e  and  binds  the  resulting  value  to  the  identifier  x.  For  example: 


3.3.3  Functions 

The  general  form  of  a  function  definition  is  let  f  x  =  e,  where  x  is  a  formal  parameter,  and  e  the 
body  of  the  function.  For  example  we  can  define  the  successor  fiinction  as  follows: 

:;'7  =  -  :  cat  cnc 

inc 


Note  that  the  type  inferencing  mechanism  of  ML  means  that  the  type  of  succ  has  been  inferred  to  be 
int  ->  int  without  having  to  declare  x  explicitly  to  be  of  type  int. 

Functions  of  several  arguments  can  be  defined: 
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>lez  add  x  y  =  x  *  y; ; 

add  =  -  :  (int  ->  int  ->  ir.t) 

».et.  add3  =  add  3;; 
add3  =  -  :  {ind  ->  int) 


*add3  5;; 
8  :  idt 


An  equivalent  notation  for  functions  is  the  lambda-expression.  A  backslash  V  is  used  to  approximate  a 
iam^  The  expression  let  f  =  \x.e  is  equivalent  to  let  f  x  =  e.  Recursive  funcUons  may 
be  denned  using  the  keyword  letrec: 


♦  let 


\  X .  X  1 ;  ; 
(i.tt  ->  i.nt) 


af 
3  ; 


i.etrec  fact  r.  =  If  ^.=0  then  1  else  n* f act  (n-1 )  ;  ; 
fact  =  -  :  Cnt  ->  int) 

•fact  5;; 

120  :  Int 


3.3.4  Lists 

All  the  elements  of  a  list  must  be  of  the  same  type: 

•  !  1 ;  2  ;  3  ;  -I ;  5  i  ;  ; 

2;  3;  4;  51  :  tnt  list 


We  have  the  following  standard  operations  on  lists: 

»nd 


•tl  :i;2;3:;; 

.2;  3;  ;  int  list 

• 'one  ’ .  : 'two 'three'!;; 

i'one';  'two';  'three '1  ;  string  list 

‘■..•2;31  a  14;5;61;; 

2;  3;  4;  5;  61  :  int  list 


3J.5  Polymorphism 

Let  us  inspect  the  type  of  the  function  hd: 

»hd;  ; 

-  ;  (*  list  ->  *) 

This  says  that  hd  has  many  types:  it  is  defined  on  any  list  of  elemenu  with  the  same  (but  aibilraiy)  type, 
(hence  the  type  variable  •),  and  returns  an  element  of  that  type.  Such  fiuictiont  are  ralM  polymorphic. 
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3.3.6  Failure 

Some  standard  functions  fail  at  run-time  on  certain  arguments: 
"  1 ,  1 ;  ; 

-vilua'i.ri  faii^ed  div 


ill-ryp«-d  phrase:  7 

V.as  an  instance  of  type  int 

which  should  match  type  *  list 

1  error  in  typing 

typecheck  failed 

Failures  can  be  trapped  with  ?,  so  the  value  of  the  expression  el  ?  e2  is  el  unless  el  causes  a 
failure,  in  which  case  the  result  is  the  value  of  e2.  A  failure  may  be  forced  as  follows: 

»faiiwith  'mistake!':; 
evaluation  failed  mistake! 


3.3.7  New  T^pes  --- — _ 

ML  is  very  flexible  in  this  respect.  We  may  .simply  abbreviate  a  type,  as  in: 

^lettype  .!trir4gp’.ir  =  string  #  string;; 

'ype  strin.gpair  iefir.ed 

or  define  a  new  type,  for  ex.ample; 

ttype  card  =  ace  >  king  i  gueen  I  jack  I  other  of  int;; 

N'ew  canstructors  declared; 

ace  :  card 

king  ;  .:ard 

gueen  :  card 

lack  :  card 

ether  :  (int  ->  ‘.'ardl 


which  declares  a  new  type  consisting  of  four  constructors:  the  constants  king,  queen  and  jack,  and 
the  function  other.  A  function  whose  argument  is  of  such  a  type  is  defined  by  the  general  expression 


funpati-ei  |  patj.e:  |  ...  |  patn-Cn 

Such  an  expression  denotes  a  function  which,  given  a  value  v,  selects  the  first  pattern  which  matches  v, 
say  pati,  binds  the  variables  of  pat;  to  the  corresponding  components  of  the  value,  and  then  evaluates 
the  expression  e. 

So,  for  example,  a  function  giving  the  standard  value  of  a  card  In  contract  bridge  is  given  by: 

»leC  value  =  fun  ace  .  4 

I  king  .  3 

I  queen  .  2 

I  jack  .  1 

I  (other  n)  .  0;; 

svalue  =  -  ;  (card  ->  int) 

Then  the  total  value  of  a  hand  of  cards  (represented  as  a  list  H)  Is  given  by; 


T 
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♦  letrec  ;o::alvalue  H  = 

if  null  H  then  0  else  value  (hd  (H)  )  *  totalvalue  (t.l(H));; 
*-ocalvalue  =  -  :  (card  list  ->  int) 


♦  totalvalue  '.ace;  king;  king;  jack;  (other  5)];; 


Recursive  types  can  be  defined:  for  example,  we  could  define  the  positive  integers  by: 

♦rectype  int  =  zero  I  succ  of  int;; 

New  constructors  declared: 

zero  :  int 

succ  :  (int  ->  int) 

New  types  can  also  be  defined  by  abstraction.  For  example  here  is  a  definition  of  an  abstract  type  called 
set,  constructed  from  a  list  of  integers.  Note  that  the  internals  of  this  type  are  hidden  from  the  user 

♦abstype  set  =  int  list 

with  rrake_set  =  \x.  abs_set  x  and 

errpty  =  abs  set  i  ;  and 

size  =  \s.  length  (rep_set  s);; 

♦  **n:ake_sec  =  -  :  (int  list  ->  set) 

empty  =  -  :  set 

size  =  -  :  (set  ->  int) 

*let  s  =  make_set  :  I ; 2 ;  3; 'I ;  5  j  ; ; 
s  =  -  :  set 

»  3 1  z  e  3 ;  ; 

5  :  int 

4 s i ze  emot y ; ; 


3.3,8  Imperative  Features 

We  have  relegated  until  last  those  features  of  ML  which  lie  strictly  outside  of  functional  languages. 
Assignable  variables  are  created  with  the  keyword  letref.  The  while  construct  is  also  avilable. 

♦  let ref  a  =  3;; 
a  =  3  :  int 

♦  a; ; 

3  :  int 

♦a  :=  7;; 

7  ;  int 


♦  a ;  ; 

7  :  int 

let  fact  n  =  letref  count  =  n  and  result  =  1  in 

while  count  >  0  do  count,  result  :=  count-1,  count*result;  result;; 
♦fact  5;; 

120  :  int 
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Chapter  4  THE  HOL  SYSTEM 

4.1  Introduction 

;  In  this  chapter  we  shall  give  an  overview  of  HOL,  a  system  Jeveloped  by  Mike  Gordon  at  the  University 

of  Cambridge.  HOL  supports  interactive  theorem  proving  in  higher  order  logic.  It  inherits  many  ideas 
from  LCF  [14],  a  good  up-to-date  account  of  which  may  be  found  in  the  book  by  Larry  Paulson  [18], 
As  in  LCF,  the  language  ML  provides  the  environment  in  which  terms  and  theorems  of  the  logic  can 
be  denoted  and  theorem  proving  takes  place. 

HOL  IS  really  a  proof-assistant  and  proof  checker.  It  will  not  prove  complex  theorems  automatically:  the 
»  user  must  have  an  idea  of  the  way  the  proof  will  work,  and  apply  the  appropriate  steps  (called  tactics)  in 

the  proof,  which  works  in  a  goal-directed  fashion.  The  HOL  system  manages  the  proof,  taking  care  of 
the  details  of  primitive  proof  steps,  and  provides  a  sound  theorem  proving  environment  —  i.e.  the  user 
is  assured  that  a  theorem,  once  obtained,  is  true  within  the  logic. 

HOL  provides  a  natural  and  highly  expressive  way  of  specifying  and  reasoning  about  models  of  abstract 
systems.  It  was  originally  suggested  as  a  tool  for  the  verification  of  hardware,  and  it  is  fair  to  say  that 
most  of  the  activity  in  HOL  is  in  hardware  (with  Mike  Gordon’s  group  at  Cambridge  primarily  involved 
111  this  area).  Nevertheless,  HOL  has  been  applied  to  other  areas,  including  protocol  verificauon  [19], 
mathematical  theories  such  as  groups  and  integers,  machine  architecture  specification  [20],  security  policy 
modelling  [21].  The  HOL  TUTORIAL  [22]  gives  several  examples.  HOL  is  just  beginning  to  be  applied 
to  the  area  of  software  verification,  which  is  the  concern  of  this  paper. 

»  The  lollowing  is  not  meant  to  be  exhaustive,  but  rather  to  give  a  flavour  of  working  with  HOL.  as  well 

as  highlighting  both  those  features  of  the  system  which  support  reasoning  about  programming  languages, 
and  those  which  hinder  such  reasoning. 


4.2  Higher  Order  Logic 

The  H(9L  logic  is  a  version  of  higher  order  logic  based  on  Church’s  formulation  of  simple  type  theory 
[2.1].  It  IS  a  variant  of  typed  polymorphic  A— calculus,  with  formulae  being  identified  with  terms  of 
boolean  type.  Variables  can  range  over  functions  and  predicates,  and  functions  can  take  other  tiinctions 
.IS  arguments  (hence  ’higher  order’).  The  important  property  of  t 

he  HOL  logic  is  that  it  is  expressive  enough  to  be  able  to  formulate  mathematical  theories:  one  might 
iliiiik  ot  It  as  being  as  formal  tool  which  replaces  the  u.sual  mathematician’s  meta-language  of  informal 
description  and  proof  with  a  formal  system  which  captures  the  same  ideas. 

An  important  notion  is  that  of  a  theory,  which  is  a  collection  of  types,  constants,  definitions  and  axioms 
—  IS  with  any  logical  system  —  but  which  also  contains  an  explicit  list  of  theorems  which  have  already 
been  proved  from  the  axioms  and  definitions,  and  perhaps  earlier  theorems.  A  HOL  theory  is  a  dynamic 
object  which  can  be  extended  or  even  modified  during  an  interaction  with  the  HOL  system. 

4.2.1  Types 

The  H(9L  logic  is  typed;  we  can  think  of  types  as  expressions  that  denote  sets.  We  shall  use  the  generic 
variable  (t  to  range  over  arbitrary  types.  The  possible  kinds  of  types  are  given  by  the  following  table 
adapted  from  [22]: 
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Table  2  HOL  Types 


Kind  of  Type 

HOL  Notation 

ML  Notation 

Description 

TVpe  variable 

a 

M.* 

arbitrary  type 

Type  constant 

c 

":op" 

fixed  type 

Function  type 

<7  ->  <7' 

"•.<7  ->  o'  " 

functions  fiom  a  \a  a' 

Compound  type 

(<7i, ....  <r„)  op 

":(<7i, ....  <7„)  op" 

general  type 
constructor 

) 


i 

i 

I 

i 

1 
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Type  variables  denote  arbitrary  (non-empty)  sets,  and  are  used  to  specify  ranges  of  types  in  the  logic. 
Type  constants,  or  atomic  types  denote  fixed  sets  of  values.  Each  theory  determines  some  collection 
of  type  constants.  Foi  example,  the  standard  constant  type  bool  denotes  the  set  of  truth  values.  The 
function  type  denotes  the  set  of  total  functions  from  the  set  denoted  by  cr  to  the  set  denoted 
by  (t'.  Finally,  the  compound  type  (tri ,  ...,  <t„)  op  gives  a  general  means  of  constructing  new  types, 
for  example  the  product  type  tri  x  <t2  =  (<ri ,  <72)  prod.  'IVpes  containing  type  variables  will  be  called 
polymorphic,  all  other  types  being  monomorphic.  An  instance  <r’  of  a  type  <r  is  obtained  by  replacing 
all  the  occurrences  of  a  type  variable  in  tr  by  a  type. 

Also  shown  in  the  table  is  the  representation  in  ML  of  the  various  kinds  of  type.  This  will  be  discussed 
later  on. 

4.2.2  Terms 

The  terms  of  the  HOL  logic  are  simply  expressions  denoting  elements  of  the  sets  denoted  by  types.  We 
shall  use  the  variable  t  to  range  over  terms.  The  following  table  summarises  the  four  kinds  of  terms 
in  the  logic; 


Table  3  Primitive  Terms  of  the  HOL  Logic 


Kind  of  term 

HOL  Notation 

ML  Notation 

Description 

Variable 

X 

"var :  <7  " 

variable  var  of  type  <7 

Constant 

c 

"const :  <7  " 

constant  of  type  a 

Application 

1 1’ 

"tt'  " 

function  t  applied  to  t' 

Abstraction 

Ax.t 

•V.  t" 

lambda  expression 

A  function  application  1 1’  denotes  the  result  of  applying  the  function  denoted  by  t  to  the  value  denoted 
by  t’.  while  the  A-term  Ax.t  denotes  the  function  v  — >  t  (v/x],  where  t  [v/x]  denotes  the  result  when 
v  is  substituted  for  x  in  L 

Although  the  terms  just  given  make  no  mention  of  types,  each  term  in  the  logic  actually  has  a  unique  type. 
If  we  need  to  be  explicit,  we  write  t<r  to  express  the  fact  that  t  is  of  type  <t.  Once  again,  we  call  a  term 
containing  a  type  variable  polymorphic.  Any  term  input  to  the  system  must  be  well-typed  according  to 
the  rules  of  the  logic.  HOL  has  a  type  checker  for  logicid  terms  based  on  the  ML  type  checking  algorithm. 

4.2J  Logical  Formulae 

Every  theory  is  assumed  to  contain  the  constant  type  boot;  it  is  an  irnportam  feature  of  the  HOL  logic 
that  logical  formulae  are  then  identified  with  terms  of  type  brxiL  The  HOL  system  does  not  distinguish 
between  them  at  all‘.  also,  various  logical  constructs  are  assumed  to  be  present  in  each  theory.  We  shall 

'  In  iMbtik'i  vcnioa  of  HiglMr  Ordtr  Logic,  lemis  cl  typo  boot  u*  diHmgaidMd  fiom  fonmilw,  bar  an  imcrehtngeable  by 
meaii  of  oeiuin  built-in  cquivilencM. 
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not  go  uuo  details,  hut  just  assume  that  the  logic  is  expressive  enough  in  that  it  contains  the  following 
eonstnicts: 


Table  4  Derived  Logical  Constructs  of  HOL 


Kind  of  term 

HOL  Notation 

ML  Notation 

Description 

Truth 

T 

"T 

true 

Falsity 

F 

"F  •• 

false 

Negation 

-it 

'."t  ■' 

not  t 

Disjunction 

t  V  t.' 

"t  V  t'  ■■ 

t  or  t' 

Conjunction 

t  A  t' 

"f  A  t'  •• 

t  and  t' 

Implication 

f  3  t' 

"t  ==>  t'  ■' 

t  implies  t' 

Equality 

t=t' 

•t  =  t'  " 

t  equals  t' 

Universal 

Quaniification 

Vx.t 

"!x.t  ■■ 

for  all  X  :  t 

Existential 

Quantification 

3x,t. 

••■.>x.t  •• 

there  exists  an  x  such 
that  t 

Unique  Exi.stentlal 
Quantiiicauon 

3!x,t 

■■?!x.t' 

there  exists  a  unique  x 
such  that  t 

f  -term 

rx.t 

■■@x.t  ■' 

an  X  such  that  t 

Conditional 

t  =>  t'  1 1" 

f  =>  t'  1 1"  " 

if  t  then  t'  else  t" 

4.2.4  Constant  Definitions 

The  HOL  logic  provides  ways  of  introducing  definitions  in  a  manner  which  preserves  consistency  of  the 
liigic,  .A  constant  definition  over  some  theory  is  an  equation  of  the  form  where 

1.  c  is  not  already  a  constant  in  the  theory; 

2.  t  IS  a  closed  term  (i.e.  has  no  free  variables);  and 
all  the  type  variables  occuning  in  itr  txtcur  in  cr. 


4.2.5  Deduction  and  Proofs 

The  HOL  logic  is  based  on  natural  deduction.  Sentences  of  the  logic  are  scqucnts,  denoted  generally 
by  r  I-  t,  where  T  is  a  set  of  boolean  terms  called  assumptions,  and  t  is  a  boolean  term  called  the 
conclusion.  If  F  is  empty,  we  write  simply  b  t. 

A  deductive  system  Q  consists  of  a  .set  of  inference  rules,  which  we  write  in  the  following  natural  style: 

Ah  ti  ...  A  b  ti, 

Ab  t 

We  read  this  rule  as  saying  that,  if  the  sequents  A  b  ti . A  b  t|,  all  hold,  then  we  can  conclude  the 

truth  of  A  b  t. 
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We  say  that  a  sequent  F  )-  t  follows  from  a  set  of  sequents  A  by  a  deductive  system  Q  if  there  are 
sequents  Fj  1-  ti .  Fn  I-  such  that 

F  h  t  =  Fn  I”  tn.and 
if  1  <  i  <  n  ; 
either  F,  )-  ti  6  A,  or 
F|  I-  t,  follows  by  means  of  Q  from 
members  of  A  U  (Fi  I-  ti, F,_i  l~  ti_i} 

The  sequence  Fi  h  ti,  ....  Fn  h  tn  is  then  called  a  proof  of  F  I-  t  from  A  with  respect  to  fl. 

4.2.6  The  HOL  Deductive  System 

We  shall  now  give  the  eight  basic  rules  of  inference  of  HOL’s  deductive  system^; 
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Table  5  Basic  Rules  of  Inference  for  HOL 
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These  inference  rules  are  natural  and  simple  ones  to  write  down,  although  the  side  conditions  on  the 
variables  involved  can  be  rather  complicated  (for  more  details  see  the  manual). 

4.2.7  Theories 

A  theory  in  the  HOL  logic  is  a  quadruple: 

T  =  (StructT.SigT.  Axiomsr.TheoremsT) 

where 

i.  StructT  is  the  type  structure  of  T; 

ii.  SigT  is  its  signature  (its  basic  constants): 

iii.  Axiomsr  is  a  collection  of  sequents;  and 

iv.  Theoremsr  is  a  set  of  sequents  in  which  every  member  follows  from  Axiomsr  by  means  of 
the  HOL  deductive  system. 

There  is  a  natural  notion  of  extension  of  a  theory:  a  theory  T’  is  an  extension  of  T  if: 

i.  StructT  C  Struct  r; 
li.  SigT  C  Sig  r; 

iii.  AxiomsT  C  Axioms  r: 

iv.  TheoremsT  C  Theorems  t'I 

If  C(7  =  t<T  is  a  constant  definition  over  T,  then  the  definitional  extension  of  T  by  C(r  =  is  the  theory 
T+,j«f(c,  =  t<,)  =  (StructT. SigT  UCff.AxiomsTU  {Cff  =  t,},TheoremsT) 

The  crucial  property  of  this  extension  is  that  it  is  consistent  if  the  original  theory  T  is  consistent. 


4J  The  HOL  Logic  in  ML 

Having  looked  a  little  at  the  HOL  logic,  we  now  need  to  discuss  its  representation  in  ML.  It  is  impossible 
to  go  into  all  the  details  here,  so  we  shall  just  go  over  some  key  points,  referring  to  the  manual  for 
further  details. 

In  the  HOL  system,  the  types  of  HOL  leims  have  the  ML  type  called  type,  while  terms  of  the  logic  have 

the  ML  type  term.  They  can  be  input  to  HOL  enclosed  in  quotation  marks;  their  explicit  form  is  shown 

in  the  tables  given  in  the  previous  section.  Various  ML  functions  exist  for  creating  and  manipulating  these 

values.  A  theorem  is  represented  in  HOL  by  a  value  of  ML  abstract  type  trim.  The  system  represents 

inference  rules  by  ML  functions  whose  arguments  are  of  type  thm  and  which  return  a  result  of  type 

chm.  HOL  contains  a  large  number  of  derived  theotems  and  inference  rules,  which  are  built  up  from  t 

the  basic  axioms  and  primitive  inference  rales  of  the  togic. 

The  system  is  soufid  in  that  the  only  way  to  obtain  theotems  is  by  generating  a  proof.  This  is  done  by 
applying  the  ML  functions  representing  inference  rales,  either  to  axioms  or  previously  generated  theorems. 

4J.1  ML  Functions  for  Handling  Theories  ^ 

A  theory  is  represented  in  the  H(X.  system  as  a  Lisp  file  called  ‘‘name.ih”.  with  'name*  being  the  name 

of  the  theory  supplied  as  an  ML  string.  Theory  files  have  a  hieiarchical  stnicture  which  represents 

sequences  of  extensions  of  an  initial  theory,  which  is  called  HOL.  A  theory  will  generally  have  one  or 

more  pamus,  of  each  of  which  it  is  an  extension.  A  session  with  the  HOL  system  consists  of  creating 

a  new  theory  by  extending  existing  theories  with  a  number  of  definitions  (and  perhaps  axioms).  There  I 

are  two  modes  of  interaction  with  HOL;  in  drqfit  mode,  a  theory  can  be  arbitrarily  extended,  but  in  proof 

mode  only  new  theorems  can  be  proved. 
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Here  is  a  summary  ot  the  most  important  ML  theory  functions: 

Table  6  ML  Theory  Functions 


save_thm  ( 'c.th) 


When  tlie  HOL  system  is  started  up.  the  initial  theory  is  called  HOL.  This  theory  has  a  complicated 
ancestry,  whose  exact  stnicture  is  not  important.  What  the  user  needs  to  know  is  that  there  are  a  certain 
numher  tu  huilt-in  theories,  which  capture  a  large  body  of  mathematical  knowledge.  These  theories  are 
:  luHii,  ind,  iium,  prim^rec,  arithmetic,  list,  tree,  cumhin,  Itrec,  tydefs,  sum  and  one.  The  HOL 
system  also  has  as  a  .set  of  u.seful  library  theories  (such  as  sets,  string,  integer  etc)  which  can  be  called 
upon  at  will, 

4.3.2  The  Type  Definition  Package 

In  our  table  of  theory  functions  earlier,  we  deliberately  omitted  a  function  called 
;.-r'.v_t/pe_aef  inicion,  which  allows  a  new  type  or  type -operator  to  be  added  to  the  theory  in  a 
conservative  (i.e.  consistent)  fashion.  This  usually  involves  a  lot  of  work.  For  many  kinds  of  types, 
this  function  has  been  superseded  by  the  new  type  definition  package  (due  to  Tom  Melham).  This 
package  automates  the  considerable  proof  effort  required  to  define  new  concrete  (possibly  recursive) 
t\pes.  Because  of  its  usefulness  for  the  study  of  language  semaniics,  we  shall  look  at  it  in  some  detail. 

The  main  ML  function  in  the  package  is 

ie  1 1  rie_’:yr -  :  a t  r  i  ng -  -s  ;  r  i r.g - > c ban 

where  the  first  string  is  a  name  under  which  we  want  the  result  to  be  stored  in  the  theory,  and  the  second 
string  IS  a  specification  of  the  type,  given  in  a  manner  rather  like  ML  compound  types.  It  is  of  the  form: 

■op  =  Cl  ty} ...ty^*  I  I  Cm  tyi,...tyJ;,-‘ 

where  each  ty^  is  either  a  type  expression  already  defined  as  a  type  in  the  current  theory  (which  must 
not  contain  op)  or  i.s  the  name  op  itself.  For  example,  we  could  define  natural  numbers  by 


extendjheory  'name' 
loadjheory  •name’ 
iiiclude.theory  'name' 


Description 

Go  into  draft  mode  for  a  new  theory  called 
name* 

Make  ‘name*  a  parent  of  the  current  theory 

Make  op  a  new  n-ary  type  operator  in  the  current 
theory 

Make  a  new  constant  of  generic  type  <t  in  the 
current  theory 

Declare  the  sequent  1-  t  to  be  an  axiom  of  the 
current  theory  with  name  c. 

Save  the  theorem  th  with  name  c  in  the  current 
theory  file 

Save  the  current  theory  and  exit  draft  mode 

Extends  the  current  theory  with  a  constant 
definition;  declares  the  sequent  be  =  Avi.  v„  t 
to  be  a  constant  definition  called  a. 

Go  into  draft  mode  for  ‘name* 

Go  into  proof  mode  for  name* 

Make  all  the  axioms,  theorems,  definitions  from 
the  theory  called  ‘name*  available. 


Fuiictu'ii 

iiew_iheory  'name' 

new_p;u'ent  'name' 
new_type  n  "op" 

new_con,stant  i'c'.cr) 

new_axKmi  ( ‘c'.t) 
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let  r!at_Axiom  =  de£ine_type  'nat_Axiom' 

'nat  =  Z  ;  Sue  nat ' ; ; 

In  this  case,  Z  stands  for  zero,  and  Sue  is  the  successor  function.  The  theorem  returned  (nat_Axiom)  is 
just  the  primitive  recursion  theorem  for  the  natural  numbers. 

The  type  package  makes  it  easy  to  define  recursive  functions  on  these  new  types.  For  example,  we  can 
define  the  function  parity  on  elements  of  our  type  nat  by 

new_recursive_definition  false  n3t_Axiom  'parity' 

"(parity  Z  =  0)  /\ 

(parity  (Sue  x)  =  1  -  parity  (k))”;; 

When  this  is  input  to  HOL,  the  package  automatkally  proves  the  existence  of  the  primitive  recunive 
function  (in  this  case  parity),  and  declares  a  new  constant  in  the  current  thetxy  with  the  above 
definition  as  its  specification. 

The  type  package  also  gives  us  a  number  of  other  useful  theorems  automatically,  including  an  induction 
theorem  for  the  concrete  type,  a  cases  theorem,  a  theorem  stating  that  the  constructors  are  one  to  one, 
and  so  on. 

4.4  Goal  Directed  Proof 

It  is  possible  to  carry  out  proofs  in  HOL  in  a  forwards  manner,  starting  from  known  theorems  and 
repeatedly  applying  inference  rules  until  the  required  result  is  obtained. 

In  practice,  however,  it  is  very  awkward  to  do  proofs  this  way,  and  proofs  are  almost  always  not  carried 
out  forwards,  but  in  a  more  natural  goal-directed  fashion  invented  by  Robin  Milner  for  LCF.  We  begin 
with  the  goal,  and  then  try  to  reduce  the  goal  to  a  number  of  subgoals,  whose  validity  implies  that  of  the 
I  original  goal.  These  subgoals  are  successively  decomposed,  until  eventually  we  reach  known  facts. 

4.4.1  Tactics  and  Tacticals 

To  implement  this  idea  in  LCF,  Milner  invented  the  notion  of  tactics.  A  tactic  is  an  ML  function  which, 
when  applied  to  a  goal: 

1 .  reduces  a  goal  to  a  list  of  subgoals,  and 

2.  provides  a  “proof  function’'  which  justifies  why  solving  the  subgoals  will  solve  the  goal. 

In  ML,  we  have  the  following  type  abbreviations; 

tactic  =  goal  ->  subgoals 

goal  =  term  list  #  term 

subgoals  -  goal  list  #  proof 
proof  -  thm  list  — >  thm 

We  say  that  a  tactic  solves  a  goal  if  it  reduces  the  goal  to  the  empty  list  of  subgoals. 

I  Thctics  are  specified  as  follows; 


goal 

goal  I  goalj  ...  goal„ 

HOL  has  a  rich  supply  of  tactics.  For  example,  we  have  the  lactic  CONJ_TAC; 

A  A  B 
A  5 

which  expresses  the  fact  that,  if  we  want  to  prove  the  formula  A  A  B,  it  suffices  to  prove  the  subgoals 
A  and  B,  because  we  know  that  from  H  A  md  I-  B  we  can  deduce  the  thearem  h  A  A  B,  The  inference 
rule  which  does  this  is  called  COH  J. 


i 
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It  IS  interesting  to  look  at  the  ML  code  for  CONJ_TAC; 


-AC  :  3sl,  w  = 


The  code  shows  how  the  suhgoals  are  constructed,  how  the  proof  function  is  built  using  COKJ,  and  what 
happens  if  the  tactic  fails.  Even  such  a  simple  example  also  shows  how  painful  the  writing  of  tactics 
as  ML  procedures  can  be! 

In  practice,  new  tactics  are  usually  built  using  ML  functions  called  tacticals.  An  example  of  a  tactical 
is  the  sequencing  tactical  THEN;  if  Tj  and  Ti  are  tactics,  T:  THEN  T2  is  a  tactic  which  first  applies 
Ti  to  the  goal,  and  then  applies  T2  to  each  resulting  subgoal.  Another  impor  mt  tactical  is  OREL3E  : 
Ti  OREL3E  Tt  is  a  kind  of  "choice”  tactic  which  applies  Ti  to  the  goal,  unless  it  fails,  in  which  case  it 
applies  T:.  The  tactical  REPEAT  is  for  iteration  ;  REPEAT  T  keeps  applying  T  until  it  fails. 

Becoming  a  HOL  expert  means  becoming  familiar  with  a  range  of  tactics,  and  the  situations  where  they 
can  be  applied.  By  using  tacticals  (which  we  might  also  term  strategies),  we  can  build  quite  powerful 
and  sophisticated  tactics,  tailor-made  for  the  problem  domain  being  studied. 


4.4.2  The  Subgoal  Packa^f* 

In  order  to  allow  interactive  to  be  carried  out,  the  HOL  system  is  provided  with  a  subgoal  package 
(along  the  lines  of  LCF'sl  which  takes  care  of  proof  management.  It  traverses  the  tree  of  subgoals 
depth-first,  The  currcat  goal  can  be  expanded  into  subgoals,  which  are  kept  on  a  goal  stack.  Once  a 
tactic  solves  a  su^-goal,  the  pack,age  automatically  applies  the  appropriate  proof  functions  to  compute  pan 
of  the  proof,  .iiid  then  and  shows  the  next  subgoal  to  be  proved.  Unfortunately,  the  subgoal  package 
Joes  have  in  hmitations,  but  is  to  be  improved  in  future  versions  of  HOL. 

Here  is  m  ex.imple  of  a  rather  .irtificial  but  simple  interactive  proof.  First  we  set  the  goal  to  be  proved 
using  the  tunclion  g  :  term  ->  void: 

■ .  H;  .y.r/izl  =  X :  .  ?  n :  uum .  '  ,  n  =  j ;  1  “ ;  ; 

[x:y : zl  =  x:  In.  'n  =  Oil" 

Hus  goal  IS  expanded  into  two  .subgoals  with  CCNJ_TAC: 

3-vr  ;;MJ_TAC;  r 


Let  us  examine  the  first  (bottom)  subgoal,  which  is  an  obvious  assertion  about  lists  of  arbitrary  elements. 
To  prove  this  subgoal,  we  simply  rewrite  with  the  definition  of  the  head  of  a  list: 

; 

-  !h  t.  HD  (CONS  hr.)  =  h 
-rx[..:,d  ,p;EWl<ITE_TAC  [HDl);; 

K  .  . 

j'.ai  proved 

I  -  !x  y  z .  HDlxiy; zl  =  x 
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Previous  subproof: 

"?n.  ' (n  =  0) " 

HOL  now  displays  the  remaining  subgoal,  which  states  the  (again  obvious)  fact  that  there  is  some  number 
distiiKt  from  zero.  We  only  have  to  find  a  suitable  n:  the  value  1  =  SUC  0  will  do.  We  expand  the 
goal  with  EXISTS_TAC: 

♦  expand  (EXI3TS_TAC  "S'JC  0*');; 

OK.  . 

(SUC  0  =  0)  " 

This  goal  is  solved  immediately  by  rewriting  with  the  derived  theorem  NOT_SUC; 

*NOT_SUC; ; 

I  -  ;n.  ' (SUC  n  =  0) 

♦  expand  (REWRITE_T.'tC  (NOT_SUC!);; 

OK.  . 

goal  proved 
'  -  -  (SUC  0  =  0) 

?n.  '(n  =  0) 

(Ix  y  z.  .HD[x;y;zJ  =  x)  /\  (?n.  '(n  =  0)) 

Previous  subproof : 
goal  proved 

The  above  proof  looks  even  simpler  if  we  use  tacticals  (THENL  is  like  THEN  but  can  apply  different 
tactics  to  the  resulting  subgoais). 

♦g  "(!x  y  z : ' . HD  (x;y;zl  =  x)  /\  (?n:num.  ' (n  =  C))”;; 

"(!x  y  z.  HD!x;y;zl  =  x)  /\  (?n.  ' (n  =  0))" 

♦  e  (C0NJ_':aC  THENL  i;rEWR:TE_TAC  '.HDl; 

EX:STS_TAC  "SUC  3"  THEN  REWRIT£_TAC  [NOT_SUC] ) ) ; ; 

♦cx. . 

goal  proved 

■-  (lx  y  z.  HD!x;y;zi  =  x)  /\  (Tn.  ' (n  =  0)) 

Previous  subproof: 
goal  proved 


There  are  a  number  of  functions  provided  for  interaction  with  the  subgoal  package,  the  most  important 
of  which  are  summarised  in  the  following  table: 


Table  7  Subgoal  Package  Commands 


Function 

Description 

g  t 

initialises  the  subgoal  package  with  a  new  goal 

expand  (or  e) 

applies  a  tactic  lo  the  top  goal  on  the  stack 

backup  (oc  b) 

backs  iq>  to  the  previous  proof  state 

rotate  (oc  c) 

rotates  the  order  of  subgoals  on  the  stack 

pcint_state  (or  p)  n 

displays  n  levels  of  the  goal  stack 

get_state 

returns  the  current  goal  stack 

set_stat6  3 

resea  the  goal  stack  to  s 
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Chapter  5  PROGRAM  VERIFICATION  IN  HOL 

5.1  Introduction 

Whatever  oiir  predisposition  may  he  about  the  best  way  of  describing  the  semantics  of  programming 
languages,  it  is  often  the  case  that  a  given  automated  theorem  prover  will  make  it  more  natural  and  easier 
for  us  to  adopt  one  particular  meth'jd.  This  is  perhaps  somewhat  surprising. 

The  early  theorem  prover  LCF  was,  of  course,  devised  with  domain  theory  (and  denotational  semantics) 
in  mind.  LCF  has  as  built-in  constructs  the  notions  of  partial  orderings,  bottom  elements,  continuity  etc. 
LCF  tiuns  all  sets  into  domains,  with  artificially  added  bottom  elements  if  necessary:  all  functions  are 
to  be  ci'ntiiiuous.  LCF  is  a  slow  system,  and  is  apparently  no  longer  available  or  supported,  owing  to 
the  rise  of  interest  in  HOL. 

Now  HOL's  logic  is  not  directly  tailored  to  reasoning  about  programs;  it  is  a  general  purpose  logic, 
powerful  enough  to  express  mathematical  theories.  The  logic  does  away  with  LCF's  annoying  habit 
of  lifting  .sets  like  Nat  (the  natural  numbers).  Therefore,  where  possible,  proofs  of  such  laws  as  the 
ass(x;iative  law  for  arithmetic 


X  -b  ( y  -f  z)  =  (x  -b  y)  -b  z  Vx,  y ,  z  6  .Nat 

can  be  proved  without  having  to  reason  about  cases  such  as  x  =  ±.  This  makes  using  HOL  a  lot  easier. 
However,  the  price  one  pays  for  this  is  the  need  to  import  the  relevant  parts  of  domain  theory  as.  and 
when,  they  become  necessary. 

Despite  these  considerations,  we  claim  that  HOL  is  useful  for  formulating  denotational  semantics 
definitions,  and  reasoning  about  program  correctness,  for  the  following  reasons: 

1 .  syntax  specifications  in  BNF  form  are  ea.sily  modelled  in  HOL  by  establishing  new  compound 
(possibly  recursive)  data  types  using  the  type  package: 

2.  common  semantic  algebras  (for  example  natural  numbers,  strings,  lists)  are  either  already 
pre.sent  iii  HOL  or  its  libraries: 

?.  HOL's  logic  IS  cxpre.ssive  enough  to  capture  the  .semantic  equations,  with  the  meaning  of  a 
phra.ses  being,  in  general,  a  recursively  defined  function  on  the  new  data  types  defined  above; 
4.  assertions  about  program  phrases  are  easily  expressed  in  HOL;  and 
.■s.  many  tedious  proofs  in  denotational  semantics  can  be  taken  care  of  by  simple  rewriting. 

What  about  operational  semantics  definitions?  We  claim  that  HOL  seems  less  natural  here.  Consider, 
for  example,  the  typical  rules  for  constants  and  for  the  sum  of  two  expressions: 

E  1-  v  v 


E  F  e|  —  V[  E  F  eo  — ■  vt  v  =  vi  +  va 
E  F  e|  -b  ^2  “  V 


which  we  might  formulate  as  the  following  HOL  axioms: 

l-',  I.'M'IbER  =  -n  ;  '  ,  "seq  'E,  Const  v, 

C’C-2-UT:  =  r.-w_sxi:;r:  ’  CCl-lMATION '  , 

"  :vl  -/a.  :aeq  :E,  -:-i,  vl)  /\  3«q  (E,  ^2 ,  v2 )  /\  iv  =  vl  .  v. 

-=>  oeq  lE,  Plus  el  e2,  v) '  );; 

Suppose  our  goal  is  "seq  (E,  Plus  (Const  5)  (Const  7), 5  +  7)  ".  We  could  solve  it  by  using 
I-IATCH_MP_TAC  and  the  axiom  for  StFMMATION.  but  then  we  have  the  variables  vl  and  v2  which  must 
be  instantiated  “by  hand”.  Thus  the  tactic  needed  to  solve  the  goal  depends  on  the  explicit  form  of  the 
goal.  Such  tactics  are  cumbersome  to  write.  What  we  really  want  is  to  be  able  to  treat  vl  and  v2  as 
scheme  variables  to  be  instantiated  automatically,  and  propagate  the  instantiations  to  the  other  subgoals. 
However,  HOL  does  not  have  a  mechanism  for  doing  this. 
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It  might  be  more  logical  to  capture  the  operational  semantics  rules  as  new  inference  rules  to  be  added  to 
HOL.  We  would  then  have  to  write  appropriate  tactics  for  them  directly  in  ML,  which  is  messy. 

However,  other  authors  have  had  some  success  with  operational  style  semantics  in  HOL.  Rachel  Roxa’ 
and  Malcolm  Newey  [11]  have  used  the  method  to  reason  about  program  transformation  for  a  smaL 
imperative  language.  Also,  Version  1.13  of  HOL  is  to  be  provided  with  some  simple  tools  for  the  study 
of  structured  operational  semantics. 

We  note  here  that  Mike  Gordon  [24]  has  had  some  success  in  implementing  axiomatic  style  semantics 
in  HOL.  He  has  constructed  the  Hoare  rules  along  with  corresponding  tactics  for  generating  verification 
conditions.  These  rules  are  proved  within  HOL  directly  from  the  denotational  semantics  of  the  language. 

In  this  chapter,  we  shall  c  ncentrate  on  capturing  denotational  semantics  definitions  within  HOL. 


5.2  The  Language  IMPl 

In  this  section  we  implement  the  imperative  language  IMPI,  whose  denotational  semantics  was  given  in 
Chapter  2.3.  To  begin  with,  we  declare  a  new  theory  called  impl,  with  string  as  a  parent  (to  handle 
identifiers).  We  also  load  some  useful  inference  rules  for  strings  and  some  special  tactics.  Note:  in  the 
following,  HOL’s  responses  will  be  omitted  —  unless  they  provide  useful  information. 

*sys;em  'rn  irpl .  ; 

.''.ew_;r.eory  'inpl';; 

.oad_library  'string';; 


5.2.1  Semantic  Algebras 

It  is  straightforward  to  formalise  the  semantic  algebras  for  IMPI  in  HOL.  Identifiers  may  be  modelled 
by  strings 


»new_type_abbrev  ('Identifier',  string”) ; ; 

The  domains  Tr  (uuth  values)  and  Nat  (natural  numbers)  arc  already  present  in  HOL  as  the  types :  bool 
and  :  nura.  However,  we  shall  need  also  the  lifted  domain  Nati,  which  we  express  as 

»iet  Nu.T.ber_Axiom  =  define_type  'Nurnber' 

'Number  =  number  num  i  undef _num ' ; ; 

»Number_Axiom  = 

-  ;f  e.  ?;  fn.  (.'n.  fn  (number  n)  =  f  n)  /\  (fn  undef_num  =  e) 

Here  we  have  used  the  type  package  to  construct  this  domain,  with  undef_nuin  being  the  undefined 

clemenL  HOL  returns  the  primitive  recursion  theorem  for  this  compound  type.  A  very  useful  feature 
of  the  type  package  is  that  it  can  prove  a  number  of  theorems  about  new  types  automatically.  We  have 
an  induction  theorem: 

♦ler  N'umber_Induct  =  prove_inauccion_chm  Number_Axiom; ; 

Number_Inducc  =  i-  !P.  (In.  ?(number  n) )  /\  P  andef_num  ==>  (IN.  P  N) 

We  also  have  theorems  which  state  that  the  constructor  functions  are  one-to-one  and  distinct,  and  a 

theorem  which  permits  case  analysis: 

lsave_thm  ( 'Number_one_one ' , 

prove_conscructor9_one_one  Number_Axlom) ; ; 

I-  ;n  n' .  (number  n  =  number  n')  -  (n  =  n' ) 

save_thm  ( 'Number_distlnct *, 

pcove_constructors_dlstinct  Numbet_Axiom) ; ; 
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!ri.  ■  (nurnb-ir  n  =  undei:_num) 


'<7«_';hin  ■;  '  Muttib»r_!;  Jisiss ' , 

ps.' iV'9_raii.?3_cl'itn  Mumber_Inducc ) ; ; 
i-  !M.  '"ri.  M  =  number  n)  \/  (N  *  undeC_num) 


Tlie  ftinctions  i3_number  and  is_undefin8d  act  as  discriminators,  while  get_num  retrieves  the 
number  from  a  proper  element  of  the  domain. 


♦  I-jC  XS_N'”MEER_DEF  =  riew_recur3ive_deCinition  false  rJunce 
'  :S_:fr:MBER_DEF' 

“  ( i3_nu:r'.ber  Iriumber  n)  =  T)  /\ 

!i3_r;umber  uridef_num  =  F) 

IS_NW^EER_DEF  =  _ 

I-  l!n.  is_riu[nber  (number  n)  =  T)  /\  ( is_number -undef_nu:n 


let  IS_’JHDEFINED_DEF=  new_recursive_def inition  false  Mu.mber_Axiom 
'  I3_’JNDEF1MED_DEF' 

"  ( i3_uridef  ined  (riumber  n)  =  F)  /\ 

; i3_ur.de c i Tied  undef_rium  =  T) 


»le!:  llET_:ifJl-l_DEF  =  r.ew_recur3ive_de£inition  false  t.'umber_.A;<i  im 
•dET_;rT;M_DEF' 

“tpet_r.um  (number  nl  =  n) 

(l'e“_:ium  ur.def_nu.'n  =  0) 

'.(ET_‘rjM_DEF  =  !-  (in.  get_num( number  n)  =  n)  /\  'get.num  undef-_num  = 


The  store 'also  needs  to  be  lifted:  it.s  definition  in  HOL  is  as  follows: 

wLec  3c ;'re_A.‘<i;:ti  =  def irre_cype  'Store' 

'Store  =  store  ( Identif ier->Number )  I  undef_score';; 

.‘::t''re_.A,xiotti  = 

(-  !f  e.  '?!  fn.  (!c'.  fntstore  f')  =  f  f')  /\  (fn  ur.def_store  =  ei 
Once  again,  we  have  standard  theorem.s  for  this  type: 

»let  Store_Inducc  =  prove_induction_thm  Store_A.xiom;  ; 

Store_Induct  = 

I-  IP.  (!f'.  PIstore  f'))  /\  P  undef_store  ==>  IIS'.  P  S') 
ttiec  .Store_one_one  = 

3ave_chm  (  ' Store_orie_one' , 
prove_oonstru-rtors_one_-!ne  Store_Axiom)  ;; 

.Store_one_orie  =  I-  if'  f''.  (store  f'  »  store  £'')  =  (f'  =  f'') 
xiet  Store_distirict  = 

.';ave_chrn  ( '  Store_distinct ' , 
prove_construccors_distinct  Ctore_Axiom) ; ; 
store_distirict  ■  i-  If',  "(store  £'  ■  undet_storei 
let  Store_cases  = 

save_thm  ( 'Store_cases' , 
prove_oases_thni  Store_Induct) ; ; 

Store_cases  s  I-IS'.  (Pf'.S'  »  store  C')  \/  (S’  =  undef.store) 


It  is  straightforward  now  to  define  the  operations  newstore,  access  and  update.  Note  that  the 
latter  two  (strict)  functions  are  defined  using  new_recuraive_d9f inition  to  specify  their  action 
on  every  possible  pattern. 
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#let  NEWST0RE_DE;F  =  new_def  initLion  ( 'NEWSTORE_DEF  ' , 

"( rewstore :  Score)  =  score  (\ i  .  undef_nuT.)  ” ) ; ; 

itMEWSTORE_DE?  =  newscore  =  score(\i.  undef_.'’.um) 

♦  lec  ACCESS_DEF  =  r.ew_recursive_def inition  false  SCore_Axio.’n 
'ACCESS_DEF ' 

"(access  i  (score  s)  =  s  i)  /\ 

(access  i  undef_sCore  =  undef_num) “ ; ; 

ACCE3S_DEF  = 

I-  (li  s.  access  i(store  s)  =  s  i)  /\ 

(li.  access  i  undef_stQre  =  ur!def_num) 

♦Let  L!PDATE_DEF  =  new_recursive_def inicion  false  Store_Axiom 
'LI?DATE_3EF  ' 

"(update  1  V  (store  m)  =  store  (\j.(j=i)  =>  v  I  m  j) )  /\ 

(update  i  v  'jndef_sCore  =  ur;def_store) ; 

l:pdate_def  = 

-  (:i  V  -n.  update  1  v(store  m)  =  store(\j.  ((j  =  i)  =>  v  I  j)))  /\ 
(11  V.  update  i  v  uodef_store  =  undef_store) 

This  completes  the  HOL  formalisation  of  the  semantic  algebras  for  IMPI. 


5.2.2  Syntax 

The  syntax  for  IMPI  is  neatly  captured  using  HOL’s  type  package.  Below  we  give  the  syntax  for 
expressions,  with  the  usual  auxiliary  theorems.  The  HOL  responses  are  rather  long,  so  they  are  omitted. 

Note  that  we  are  using  an  abstract  syntax  in  which,  say.  Plus  ei  e;  is  used  to  render  the  original  ei 
+  €2  in  the  concrete  syntax.  This  is  necessary  because  the  type  package  requires  constructors  to  be  of 
this  form.  It  does  have  the  advantage  of  giving  the  language  phi^s  a  uniform  appearance.  From  one 
point  of  view,  only  the  abstract  syntax  of  the  language  matters;  however,  the  big  disadvantage  is  that 
programs  written  using  it  can  quickly  become  unread^Ie,  and  are  also  difficult  to  write  because  of  the 
morass  of  brackets.  Clearly  a  parser  (from  concrete  to  abstract  syntax)  is  needed  so  that  programs  can 
be  easily  written.  This  is  easily  done  using  the  Unix  tools  yacc  and  lex. 

For  boolean  expressions  and  commands  we  have,  similarly: 

let  3Expression_Axiom  =  ae f  l.-.e  type  '3Expression ' 

'BExpression  = 

True  I 
False  I 

Equals  Expression  Expression  I 
Not  BExpression';; 

let  3Expression_Induct  =  prove_induction_thm  BExpression_Axiotn; ; 

save_thm  ( ’BExpression_one_one 

prove_constructors_one_one  BExpression_Axiom) ; ; 

save_chm  ( ’BExpression_distinct 

prove_constructors_dtstinct  BExpression_Axiom) ;; 

save_thm  ( 'BExpression_cases 

prove_cases_thm  BExpression_Induct) ;; 
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irr  -  ■;rutiand_A;<iom  =  define_i:yFe  'Command' 

'  ;;:;;r,jrid  =  :>.ip  I 

Val  Idencirier  Expression  i 
If  B Express ion  Command  Command  I 
'^hile  BExpression  Command  I 
Seq  Command  Command  I 
Diverge'  ;; 

1-"  !:i;m  i.'i  J_Iriduc!:  =  prove_induo':ion_!:hm  Ccmmand_Aj<iom;  : 

,  '  C'.;rt:r,arid_':'ne_one '  , 

pr  ;  v-_:  :'risr  ructor3_one_one  'Comma nd_Axiom)  ;  ; 

iv.i_chm  i  'C'.!tLT,and_distinoc' , 

prove_3':'ris!;rucCors_discinct  'Command_Axiom)  ; ; 

3ave_rh:n  t  '  Co:rmand_cases  ' , 

prove_oases_Ch!n  Comma nd_Induc C ) ; ; 


It  will  be  convenient  to  allow  a  list  of  commands  (this  is  a  form  of  syntactic  sugar): 

I-r  oEC.!._::EF  =  riew_l is t_reo_def ini t ion  ('SEQL_DEF', 

"vCeql  =  Ckip)  /\ 

;COtJS  command  sequence)  = 

.Seq  comitiand  ;:oeql  sequence)  )  “ )  ;  ; 

-  (iJeqlll  =  Skip)  /X 
:  I  r'.runand  sequence. 

■Seql  .C-CM.S  r  vtrm.and  sequence)  =  Seq  command  (Seql  sequence) 

To  complete  the  syntactic  description,  we  have 

!>:.fW^-ype_ai:brev  ■, '  Frograiii'',  —  tCottimand'' ) ; ; 


5.2.3  Semantic  Equations 

Now  we  are  ready  to  capture  the  semantics  of  IMPl  in  HOL.  To  make  things  as  simple  as  possible, 
we  shall  make  use  of  the  fixed-point  combinator  in  order  to  express  the  semantics  of  while  loops.  The 
fixed-point  property  is  added  as  an  axiom  to  the  theory  (this  is  reminiscent  of  LCF,  where  fixed-points 
and  partial  orderings  are  part  of  the  logic  —  not  proved  using  some  mathematical  model).  Clearly,  this 
is  a  short-cut,  and  quite  an  unsound  thing  to  do^.  We  must  promise  only  to  use  appropriate  functions  f 
for  which  domain  theory  guarantees  us  that  HX  f  is  well-defined! 

!inew_corist:anc  ''FIX', 

FIX_EQ  =  ^•sw_jxiom  ('FIX_EQ',  •!f:*->».FIX  f  a  f  (FIX  f )  "  ;  r  ; 

F:X_SQ  =  i-  !f.  FIX  f  =  f(FIX  f) 

The  semantic  equations  for  expressions  are  given  in  terms  of  the  valuation  function  EXPR,  which  is 
naturally  defined  using  new_recursive_def inition; 


^  It  would  be  sounder  to  itiiport  results  from  t  HOL  tlieury  of  domains.  Such  a  theory  ha*  been  consmucted  by  Albert  Camilleri, 
but  will  nut  be  u.sed  in  Uij.s  paper. 
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^iec  EXPR_DEF  =  new_recursive_def inition  false  Expression_Axiom 
'EX?R_DEF ' 

"(EXPR  (Const  V)  s  =  ((s  =  undef_store)  =>  undef_num  l  v) )  /\ 

(EXPR  (Var  i)  s  =  access  i  s)  /\ 

(EXPR  (Plus  el  e2)  s  = 

(is  nurr.ber  (EXPR  el  s)  /\  is_nuiTiber  (EXPR  e2  s)) 

=  >  nuncer  (get_num  (EXPR  el  s)  +  get_niim  (EXPR  e2  s)  )  I  undef  _n'jm)  " ;  ; 

EXPR  DEE  = 

-  ((v  s.  EXPR  (Const  v)  s  =  ((s  =  •jndef_store)  =>  undef_num  I  v)  )  /\ 

(11  s.  EXPR (Var  i)s  =  access  i  s)  /\ 

(lei  e2  s  . 

EXPR  (Plus  el  e2) s  = 

( ( is_number (EXPR  el  s)  /\  is_number (EXPR  e2  s) )  => 
nunber  (  (get_num  ( EXPR  el  s))  (get_num(EXPR  e2  s)))  I 
unde  f_num) ) 

For  boolean  expressions  we  have 

*iet  300L_EXPR_DEE  =  new_recursive_def inition  false  3Expression__AxiorTi 
'300L_EX?R_DEE  ' 

"(300L_EXPR  True  s  =  T)  /\ 

(BOOL^XPa  False  s  =  F)  /\ 

(3C0u_EX?R  (Equals  el  e2)  s  =  (EXPR  el  s  =  EXPR  e2  s))  /\ 

(300L_EXPR  (Not  b)  s  =  ' (BOOL_EXPR  b  s))";; 

3C0L_EX?R_DEF  = 

-  (Is.  3C0L_EXPR  True  s  =  T)  /\ 

(Is.  3C0L_EXPR  False  s  =  F)  /\ 

(lei  e2  3.  300L_EXPR (Equals  el  e2)s  =  (EXPR  el  s  =  EXPR  e2  s>)  /\ 

(lb  s.  300L_EXPR (Not  b)s  =  ■300L_EXPR  b  s) 

The  semantics  of  commands  and  programs  is  given  by  similar  functions,  after  which  we  close  the  theory. 

*let  COMMAND_DEF  =  new_recurslve_def inition  false  CotTmand_Axiom 
'CCyMAND_DEF ' 

"(COMMAND  Skip  s  =  s)  /\ 

(COMMAND  (Val  i  e)  s  = 

(s  =  undef_store)  =>  undef_store  I  update  i  (EXPR  e  s)  s)  /\ 

(COMMAND  (If  b  cl  c2)  s  = 

(s  =  undef  score)  =>  undef_stoce  I 
((BOOL_EXPR  b  s)  =>  (COMMAND  cl  s)  I  (COMMAND  c2  s)))  /\ 

(COMMAND  (While  b  c)  s= 

FIX  (\f  c.(BOOL_EXPR  b  t  =>  f  (COMMAND  c  t)  I  t) )  s)  /\ 

(COMMAND  (Seq  cl  c2)  s  = 

(s  =  undef_store)  =>  undef_store  I  COMMAND  c2  (COMMAND  cl  s) )  /\ 

(COMMAND  Diverge  s  =  undef_store) ; 

CCMMAND_DEF  = 

(Is.  COMMAND  Skip  s  =  s)  /\ 

( 1  i  e  s . 

COMMAND (Val  i  e)s  = 

((s  =  undef_store)  =>  undef_store  I  update  KEXPR  e  s)s))  /'  • 

(lb  cl  c2  s. 

COMMAND (If  b  cl  c2)s  » 

((s  =  undef_store)  => 
undef_store  I 

(BOOL_EXPR  b  s  ->  COMMAND  cl  s  I  COMMAND  c2  s)))  /\ 

( lb  c  s.  J 

COMMAND (While  b  c)s  > 

FIX(\f  t.  (BOOL  EXPR  b  t  ->  f {COfmAND  c  t)  1  t))S)  /\ 
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‘-■CNWA.'JD (iJecj  cl  c2)s  = 

j  -  iir.;;et'_3tor«)  =>  und«f_st:.5r'?  I  COMMAND  c2  (COMMJi^ND  :;1  )  i  i  /  , 

I-'.  J.l'y.AND  Diverge  s  =  undee_3Core) 

3l-r.  TF:;  ,;?.-2'I_DEF  =  new_def inicion  ( '  PF.OGPAM_DEF ' , 

'TF.CF.AM  ‘p:  Program)  =  \n.let  s  =  (update  'input'  n  r.o-v/srorei  in 
iec  '  3  (COMMAND  p  s)  in  (access  'output'  s ' )  “ '  ;  ; 

PF‘, '  jF'AM_,DEF  = 

'  -  Ip. 

PF.;CFA2-I  p  = 

i  \  n . 

let  s  =  update  'input'  n  newstore 

ITl 

let  3'  =  COMMAND  p  s  in  access  'output'  s') 


3cl  :-se_th6ory  ( j  ;  ; 


5.3  Reasoning  about  Programs  in  IMPl 
5.3.1  Tactics 

As  with  any  user-constnicted  theory,  we  need  a  number  of  tactics  which  are  appropriate  for  the  kind  of 
problems  we  wish  to  solve.  In  the  following  STRING_RULE  recursively  searches  terms  and  rewrites 
string  e.xpressions  such  as  'a'  =  'a'  as  T  (true)  and  'a'  s  'b'  to  F  (false);  STRING_TAC  is 
the  corresponding  tactic.  Next  we  have  rules  and  tactics  for  comparing  and  adding  numbers,  and  for 
comparing  fitnctions.  Finally,  we  shall  need  two  tactics  which  carry  out  case  analysis  on  variables  of 
type  store  and  Command. 

1-t  i:TF:;;o_T.AC  =  conv_t.ac  (DEPTH.conv  string_EQ_ccfrv’) ; 

Ir-t  STF::M_F'CLE  =  CCtA'_RULE  (DEPTH.CONV  string_EQ_CON’V)  ;  ; 


1-c  ADD_T.AC  =  CONV_TAC  (ONCE_DEPTH_CONV  ADD_COfP;)  ;  ; 

l.e-  ADD_RULE  =  CONV_RULE  (ONCE_DEPTH_CONV  ADD.COtr/)  ;; 

1-'  -u:(i_EQ_TAC  "  “  =  CIW.TAC  ^(ONCE_DEPTH_CONV  num_EQ_COir/)  ;  ;  -  ' 

l.iC  r.u:r._EQ_RULE  =  COW_RULE  (ONCE_DEPTH_CONV  num_EQ_CON'\')  ;  ; 

1-rC  RUM.EQ.TAC  =  COMV_TAC  (DEPTH.CONV  FUN_EQ_CCNV)  ;  ; 

l-t  F"N_E:i_RULE  =  :CN''/_RULE  (DEPTH.CONV  FUN_EQ_CON\')  ;  ; 

let  C;:ninand_C.ASES_TAC  =  DISJ_CASES_THEN 

STRIP_ASSUME_TAC  (SPEC  t  Cotrmand_cases )  THEN 
(.ASM_REWRITE_TAC  [Cominand_discinct ]  )  ;  : 

let  Stcre_CASES_TAC  t  =  DISJ_CASES_THEN 

3TRI?_ASStJME_TAC  (SPEC  t  Store_cases)  THEN 
(ASM_REWRITE_TAC  [Store_distinct] ) ; ; 

Two  auxiliary  lemmas  are  needed  (  the  proofs  are  omitted): 

LEMMAl  =  1-  is.  '(s  a  unde£_store)  ■>  ” (update  i  v  s  =  unde£_store) 
LE!-1MA2  3  I-  “(update  i  v  newstore  »  unde£_3tore) 

Next  we  define  SIMPLIFY_TAC,  which  repeatedly  uses  the  definitions  of  the  semantic  operations,  along 
with  some  basic  arithmetic,  and  simplifies  environments  using  BETAiTAC  and  string_TAC.  If  these 


39 


ERL-0600-RR 


steps  are  making  no  progress,  the  goal  is  lewriten  once,  in  case  we  need  to  unfold  a  term  involving  a 
fixed-point  combinator. 

let  2EFS  =  ;  IS_L:NDEFINED_DEF; 

:s_nl:mber_def; 

GET_NCM_DEF; 

ACCE3S_DEF; 

i;?DATE_DEF; 

NEWSTORE_DEF; 

Number_one_one; 

Number_dist inct; 

Store_one_one; 

3tore_discinct; 

ADD_CLAUSES; 

LEMMA21 ;; 

let  SIMPLIFY_TAC  = 

REPEAT 

(CHANGED_TAC 

(ASM_REWRITE_TAC  DEFS  THEN 
3ETA_TAC  THEN 
3TRING_TAC  THEN 
num_Eg_TAC  THEN 
ADD^TAC  0REL3E 

(0NCE_3EWRITE_TAC  iFIX_EQl ) ) ; ; 

Our  final  collection  of  tactics  basically  carry  out  rewriting  with  the  semantic  equations. 

let  EXPR_TAC  =  REWRITE_TAC  (EXPR_DEF1  ; ; 

let  300L_EXPR_TAC  =  REWRITE_TAC  :B00L_£XPR_DEF1 ; ; 

let  CCy!MAND_TAC  =  REWRITE_TAC  (COMMAND_DEF;  SEQL_DEF1;; 

let  ?RCGRAM_TAC  =  REWRITE_TAC  (LET_DEF;  PROGRAM_DEF] 

THEN  BETA_TAC;; 

let  R'JN_TAC  =  PROGRAM_TAC  THEN 

COMMANO_TAC  THEN 
BOOL_EXPR_TAC  THEN 
EXPR_TAC;; 

The  tactics  we  have  defined  may  look  rather  ad  hoc  —  and  ate  to  some  extent  —  but  are  very  simple  in 
structure  and  easy  to  comprehend.  They  illustrate  the  fact  that  powerful  new  tactics  ate  easy  to  construct 
(using  tacticals). 


SJ.2  Example  Proofs 

We  shall  give  a  number  of  example  proofs  of  correctness  about  programs  in  IMPl  using  the  above  tactics. 
First,  some  basic  cmistants: 

let  vO  »  "number  0";; 
let  vl  »  "number  1";; 
let  v2  •>  "number  2";; 

I  let  v3  »  "number  3";; 

let  v4  ■  "number  4";; 
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"C 


VI.)  “ 
vl" 


First  we  slitill  prove  the  example  already  given  In  Chapter  2 

P[oiir,piir,  ;=  1;  if  input  =  0  then  diverge  else  skip;  output  ;=  3]  = 
I  An.n  =  0  =>  1  □  3 


The  method  of  proof  is  simple:  we  rewrite  successively  with  the  semantic  equations,  and  then  perform 
ease  analysis  on  n  =  0,  Finally,  we  simplify. 

s  [Val  'output'  ; 

If  .Equals  ;7ar  'input')  'eO) 

Dive rge 
i  else  'i 

•Ekip; 

Val  'output'  'ea]";; 

I  “  rR  :  n  =  ;  n  =  ‘vO)  =■>  ur.def_nuai  I  *v3";; 

'Vsl  '  ..utput '  C.riSt  inutiber  1)); 

I  f  :  E.yua  Is  > '/ \r  '  iriput ')  (Const  ( number  '))))Diverqe  Skip; 

■.■-,1  '  ;r'  :  r.et  (nu.tiber  ':  ))]} 

r.  -  :.u;;.i-er  "•  =;■  Mr;def_r.uin  ]  number  3!" 

-  C'riEff 

:::c-!a::d_tac  then 

.■■jL_EX?R_TAC  THEN 
EXr.R.TAC  THEN 

ASM_C.RSES_TAC  "n  =  "'/'D"  THEN 
:':MPLir'/_TAC)  ;  ; 

proved 
'  -  RRCQRA.M 
:S-ql 

'O'Utp’it '  iCinst  (nuinber  1)1; 

I f ; Equals iVar  ' input ')) Const  1  number  0)))Diverge  Skip; 

'7al  '  lutput '  iCoTist  (number  3  )  )  1  ) 

I  in  =  number  0)  =>  undef_num  I  number  3) 

Pr-  .lus  subprc.or: 

;;oai  proved 

This  is  quite  a  simple  program,  hut  it  immediately  highlights  some  problems.  Firstly,  it  is  very  slow 
(on  a  Sun  Sparcstation  1+,  this  proof  took  about  7  minutes,  and  generated  more  than  46.000  primitive 
inferences).  Secondly,  if  the  proof  is  done  interactively,  the  intermediate  goals  are  horribly  long  (taking 
five  or  more  screens  to  display).  This  is  because  there  is  as  yet  no  straightforward  facility  for  abbreviating 
terms  in  HOL. 

Our  second  example  shows  the  unfolding  of  a  while  loop  (the  proof  takes  about  15  minutes): 
P[otitput  =  0;  while(not(input  =  1))  input  ss  input  +  1;  output  =  output  +  1;]  0  =  1 
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g  "PROGRAM 

(Seql  iVal  'output'  '“0; 

While  (Not  ih-i-dls  (Var  'input')  'el)) 

(Seql  iVal  'input'  (Plus  (Var  'input')  'el); 

Val  'output'  (Plus  (Var  'output')  'el)!)') 
'vO  =  'vl";; 

e  (R'JN_TAC  THEN 

3:MPLIFY_TAC  then 
RUN_TAC  THEN 
SIMPLIFY_TAC) ; ; 

OK.  . 

goal  proved 
i-  PROGRAM 
(Seql 

[Val  'output '  (Const  ( nuitber  0)); 

While 

(Not  (Equals  (Var  '  input ')  (Const  (number  1)))) 

(Seql 

[Val  '  input '  (Plus (Var  '  input ')  (Const (number  1))); 

Val  'output  '  (Plus (Var  'output ')  (Const (number  !)))])]) 
(number  0)  = 
number  1 


Previous  sunproof: 
goal  proved 


Several  examples  of  equivalence  have  also  been  proved  using  HOL,  including  the  following: 


ei  +  eo  as  ej  +ei 
c;  skip  as  c 
c:  diverge  as  diverge 


We  shall  give  the  proofs  of  just  two  equivalences: 


if  b  then  C|  else  C2  as  if(not  b)  then  cj  else  Ci 


g  "COMMAND  (If  b  cl  c2)  =  COMMAND  (If  (Not  b)  c2  cl)";; 

e  (FUN_EQ_TAC  THEN 
GEN_TAC  THEN 

COMMAND_TAC  THEN  BOOL_EXPR_TAC  THEN 
COND_CASES_TAC  THEN  C0ND_CA3ES_TAC  THENL 
(SIMPLIFY_TAC  ; 

SIMPLIFY_TAC; 

TRIVIAL_TAC  ; 

REWRITE_TAC  (]]);; 

OK.  . 

goal  proved 

I-  COMMANDdf  b  cl  c2)  =  COMMAND  {If  (Not  b)  c2  cl) 


Previous  subproof: 
goal  proved 


X  :=  0;  Y  :=  X  +  I  *«  Y  :=  1;  X  :=  0 
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I  '■  O:  [Val  'x'  'eO; 

VaI  'y'  (Plus  (Var  'x')  *el)])  = 

.:;;'2-!.=iND  rval  'y-  'el;  Val  'x'  *eO])”;; 

-  r.'ri_p>;;_TAc  then 
JEN_rAC  THEN 

:'M-:Ar:r_TAc  then 

EX.-F.TAC  THEN 

Tcore_CASES_TAC  "S’;SCore"  THEN 
TIMPLIFY.TAC  THEN- _  - 

rT;N_E-Q_TAC  THEN 
EETA_TAC  THEN 
3EN_TAC  THEN 

::nd_caees_tac  then  ccmd_cases_tac)  then 

EIMPLIEV_TAC  THEN 

pewe:te_asl_with_asl_tac  (D  then  ' 

.,CHANOE_ASM_TAC  1  3TRING_RULE)  THEN 
ASM_RSWRITE_TAC  [ ; ) ; ; 

.il  proved 
-  J :  •0!AMD 
,  o  r-q  1 

[Vhi  'x‘  (Const ( number  0)  )  ; 

Val  "/'fPlusiVar  ' x' ) (Const ( number  1)))1)  = 

T;:!MA;;l‘ :v-?ql  [Val  ’•/' .Const 'number  l));Val  'x' (Const '.number  0  ;  :•  ]  i 

Previo'us  subproo:': 
proved 
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Chapter  6  ISABELLE 

l  In  iliis  chapter,  we  .shall  discuss  the  theorem  prover  Lsabelle,  which  has  been  under  development  by  Larry 

Paulson  at  the  University  of  Cambridge  since  l‘J86.  Isabelle  is  also  a  descendant  of  the  LCF  system. 
However,  it  is  based  on  quite  different  basic  concepts,  and  has  a  number  of  features  which  make  it 
different  from  HOL.  As  in  HOL,  formulae  are  manipulated  by  the  language  ML  (in  this  case  Standard 
ML),  and  the  system  provides  for  backwards  proof  by  means  of  tactics  and  tacticals. 

The  main  source  for  this  chapter  is  the  Isabelle  manual  [25],  The  theory  underlying  Isabelle  is  discussed 
in  [26.  27], 


6.1  Basic  Concepts 

Isabelle  is  a  generic  theorem  prover;  the  logic  of  discourse  is  not  fixed,  but  can  be  chosen  from  a  number 
of  built-iii  logics  provided  with  the  system,  or  even  defined  ab  initio  (although  this  is  very  difficult). 
Isabelle  has  an  expressive  meui-logic,  in  which  the  inference  rules  and  axioms  of  object  logics  can  be 
formulated.  Isabelle  comes  with  a  number  of  object  logics,  including  First  Order  Logic  (FOL),  Higher 
Order  Logic  (HOL)  and  Constructive  Type  Theory  (CTT). 

Note:  when  n  .cessary  to  avoid  confusion  we  use  "HOL”  to  refer  to  Mike  Gordon’s  HOL  system,  and 
Isabelle-HOL  to  refer  to  Higher  Order  Logic  as  captured  as  an  object  logic  within  Isabelle. 


6.1.1  Isabelle’s  Meta*Logic 

The  meta-logic  used  in  Isabelle  is  intiiitionistic  higher  order  logic  with  universal  quantification  and 
equality.  It  was  chosen  as  being  the  minimal  logic  capable  of  formulating  the  axioms  and  rules  of 
arbihary  object  logics. 

The  table  below  shows  the  constructs  used  in  the  meta-logic,  and  their  keyboard  equivalents 


Table  8  Isabelle  Meta-Logic  Constructs 


( 


I 


f 


.Notation 

Keyboard 

Description 

a  =  b 

a  ==  b 

meta-equality 

0  =>  ti' 

meta-implication 

(  ..-o,,  V) 

o 

o- 

3 

II 

II 

V 

nested  implication 

Ax.0 

!x.^ 

meta-quantification 

Ax.0 

%x.^ 

meu-abstraction 

’P 

’’P 

scheme  variables 

Pure  Isabelle  contains  the  material  common  to  all  logics:  theories,  rules,  tactics,  subgoal  commands, 
types  and  terms. 
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6.1.2  Object  Logics 

An  object  logic  is  an  ML  object  of  type  theory.  The  axioms  and  rules  are  of  type  thm.  Various  symbols 
are  used  in  object  logics;  some  of  their  keyb^d  equivalents  are  given  below: 


Table  9  Object  Logic  Symbols 


Notation 

Keyboard 

Description 

pdQ 

P--  >Q 

Implication 

P~Q 

P<->Q 

Bi-implication 

Vx.P 

ALL  x.P 

Universal  quantification 

3x.P 

EX  x.P 

Existential  quantification 

-P 

~  P 

Negation 

Isabelle  emphasises  the  natural  style  of  reasoning.  To  illustrate  this,  we  give  the  natural  deduction  system 
for  intuitionistic  first  order  logic.  Each  logical  connective  may  have  elimination  or  introduction  rules. 
For  example  the  rule  for  implication  elimination  (denoted  by  D  E)  is  just  the  well-knovm  law  of  modus 
ponens  in  first-order  logic. 


Table  10  Intuitionistic  First  Order  Logic 


Introduction  (I) 

Elimination  (E) 

Conjunction 

A 

B 

AM 

AM 

.•\irB 

A 

B 

Disjunction 

A 

B 

A  V  B  [A]  C  [B]  C 

AVB 

A  VB 

C 

Implication 

Contradiction 


[A]  B 
A  D  B 


A 

B 
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Table  10  (Continued)  Intuitionistic  First  Order  Logic 


Universal 

Quantifier 

A 

Vx.A 

Vx.A 

A[t/x] 

Existential 

Quantifier 

A[t/xj 

3x.A  [A]  B 

3x.A 

B 

6.1.3  Inference  Rules 

Isabelle  works  with  inference  rules  expressed  in  a  natural  deduction  style.  We  shall  show  how  inference 
rules  are  “packaged”  within  Isabelle.  Consider  the  rule  &I.  In  the  meta-logic,  this  is  expressed  as 
follows: 

AAB.A  =>  (B  =>  AtB) 

which  eventually  is  rendered  into  the  following  keyboard  characters: 

[jA;  B|]  ==>  A&B 

(Actually,  the  variables  involved  are  treated  internally  as  scheme  variables  ?A  and  .’B,  which  may  be 
instantiated  during  unification). 

6.1.4  Subgual  Package 

As  with  HOL,  Isabelle  carries  out  goal-directed  proofs,  and  contains  a  subgoal  package  to  assist  with 
interactive  proof.  A  proof  stale  consists  of  a  goal,  along  with  a  number  of  subgoals  whose  validity 
establishes  that  of  the  goal.  The  subgoals  can  be  thought  of  as  proof  obligations.  Diagrammatically  we 
display  a  proof  state  as  follows: 


goal 

.siibgoali 

siibgoalj 


When  we  set  a  goal  in  Isabelle  we  have  as  our  initial  proof  state 

goal 

goal 

in  which  there  is  a  single  subgoal  identical  with  the  original  goal.  When  we  reach  a  proof  state  with 
no  subgoals,  we  clearly  have  a  proof  of  the  original  goal.  As  in  HOL,  tactics  are  available  to  transform 
proof  states  to  new  proof  states,  using  the  ML  function  by.  However,  there  is  a  crucial  difference.  In 
LCF  and  HOL,  a  tactic  either  gives  a  unique  new  proof  state,  or  fails.  But  in  Isabelle  a  tactic  can  return 
more  than  one,  and  possibly  even  an  infinite  number,  of  new  proof  states  (how  this  can  happen  we  shall 
see  shortly).  If  T  is  a  tactic,  and  <t)  a  proof  state,  then  the  result  T0  of  applying  T  to  is  written  as  a 
list  to  capture  the  various  alternatives: 

T<^  =  (  ]  (failure) 

=  [V*]  (unique  result) 

=  [tf'i, t(>2, il'a, ...)  (multiple  outcomes) 
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The  possibility  that  a  tactic  can  have  multiple  outcomes  has  a  profound  effect  on  the  way  one  thinks 
about  theorem  proving  in  Isabelle.  The  user  tends  to  think  on  a  grander  scale:  a  proof  state  is  usually 
presented  with  all  of  its  subgoals  shown  (contrast  this  with  HOL,  where  one  only  sees  one  subgoal  at  a 
time),  and  a  number  of  proof  strategies  act  on  a  number  of  subgoals,  automatically  instantiating  variables 
and  renumbering  the  subgoals  as  appropriate. 

6.1.5  Tactics 

Pure  Isabelle  has  a  number  of  basic  tactics  (object  logics  come  with  a  number  of  special  purpose  tactics). 
We  shall  discuss  the  most  important  of  these. 

Recall  that  Isabelle  emphasises  the  natural  style  of  reasoning:  correspondingly,  most  proof  steps  are 
carried  out  backwards  reasoning  using  inference  rules  of  the  theory.  This  is  called  resolution.  Isabelle 
provides  a  single  ML  function  to  do  this  (again,  this  is  an  improvement  ovo^  HOL,  where  a  new  tactic 
written  in  ML  must  be  provided  for  each  new  inference  rule). 

The  basic  resolution  tactic  is  resolve_tac  thma  i.  This  tactic  tries  each  theorem  (object  logic  rule) 
in  the  list  thms  against  subgoal  i  of  the  proof  state.  For  a  given  rule,  say 

[|  B,,...,Bw|]==>B 

resolution  can  form  the  next  state  by  unifying  the  conclusion  with  the  subgoal,  replacing  it  by  the 
instantiated  premises.  Thus  if  the  subgoal  is 

[I  Ai,  ...,  An  I]  ==>  A 

and  A  can  unify  with  B,  resolution  will  produce  the  following  new  subgoals: 

(I  Ai,  ....An  )]  ==>  Bi 

[|  aT . a;  |]  ==>  K 

in  which  the  overbars  denote  the  resulting  formulae  after  instantiations  have  been  made.  Subgoals 
frequently  change  their  appearance  as  instantiations  propagate  throughout  the  proof  tree  —  something 
which  users  of  HOL  will  find  strange  at  fine 

Note  that  unification  in  Isabelle  is  full  higher-order  unification  (ie  solving  equations  in  the  typed 
A -calculus  with  respect  to  a,  0  and  ri  conversion).  There  can  be  multiple  outcomes,  arising  from 
the  fact  that  there  can  be  more  than  one  higher-order  unifier.  Multiple  outcomes  can  also  arise  if  mote 
than  one  theorem  can  be  resolved  with  the  goal.  The  tactic  will  fail  if  none  of  the  rules  can  be  unified. 

Another  fundamental  tactic  is  a3sume_tac  i.  which  tries  to  solve  subgoal  i  by  assumption  (again, 
this  may  involve  unification). 

Reasoning  about  definitions  and  deriving  new  rules  is  facilitated  by  a  number  of  rewriting  tactics.  For 
example,  rewrice_9oal3_cac  thm3  uses  the  given  definitional  theorems  for  rewriting  subgoals. 
Rewriting  is  not  as  prominent  in  Isabelle  as  it  is  in  HOL.  In  fact,  it  is  frowned  upon:  if  we  define  a 
new  constrtKt  in  a  theory,  the  preferred  strategy  is  to  derive  immediately  elimination  and  introduction 
inference  rules  for  the  construct,  and  thereafter  to  use  these  new  rules  in  resolution  steps.  Rewriting  with 
the  original  definition  can  introduce  unwanted  complexity  to  a  proof. 

6.1.6  A  Simple  Proof 

To  illustrate  theorem  proving  in  Isabelle,  consider  a  simple  proof,  namely  the  obvious  fact  in  first-order 
logic  that 


P&Q  D  (R  D  PlcR) 

A  step-by-step  proof  is  given  below.  We  first  set  the  goal,  and  then  resolve  twice  with  the  rule  d  I. 
The  conjunction  is  then  artwirxi  by  resolving  with  &I.  This  gives  two  subgoals,  the  second  of  which 
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is  solved  hy  assumption,  and  the  first  by  t^El.  Using  assumption  again  solves  the  goal:  the  result  is  a 
theorem  wliieh  Isabelle  echoes  with  scheme  variables. 

-  jcsl  Int.Rule.thy  "P&Q  -->  (R  -->  ptR)"; 

?  S:  ;  R  -->  P  &  R 

Q  R  --5.  p  s,  R,- 

-  hy  {resolve_cic  [imp_inCrl  1)  ; 

I'.-Vrl  1 

r  V  vj  R  -->  ?  ft  R 

1 .  P  ft  =  =  >  R  -  -  >  P  .ft  R 


--  hy 


t  .ft  Q  ~  >  P.  “  ”  >  r  ft  R 
1.  [1  F  ft  Q;  R  1]  ==>  P  ft;  R 

-  by  :resoive_cac  :coni_incr ] 
L'Svel  3 

P  ft  Q  R  -->  ?  .ft  R 
1.  [!  P  ft  -.D;  P  '1  ==>  ? 


1)  ; 


-  by  '  assuir.e_Cac  ji; 

Lev,?  I  A 

Pfti  -->?-->?  ft? 

1.  :  i  ?  .ft  R  1  I  =  =  >  P 

ca','  f c.jr.junocll  1)  ; 

>  ?  ft  ?. 

?  I ;  ==>  p  ft  ?Q3 
t:v:  1)  ; 

*  >  ?  ft  ? 


prch  {eesultO): 

:P  ft  7Q  ?R  :■?  ft  ?R 


-  ::  y  .  .ij'sueie. 

P  •<  T  R 
aubgcalsl 


-  by  ire3ol.ve_ 

?  ft  C; 


6.1.7  Tacticals 

Single-step  proofs  such  as  the  one  above  are  much  too  laborious.  As  with  LCF  and  HOL,  tacticals  are 
available  to  build  new  tactics  from  basic  tactics.  A  selection  of  basic  tacticals  is  as  follows: 


tael  THEN  tac2 
tael  ORELSE  tac2 
REPEAT  tac 
DEPTHFIRSTpredtac 

However,  because  tactics  can  have  multiple  outcomes,  these  tacticals  are  more  high-powered  than  their 
counteri^arts  in  LCF  and  HOL.  They  work  by  combining  sequences  of  proof  states. 

The  tactic  tad  THEN  tac2,  applied  to  the  proof  state  4>,  first  computes  tacl{(^),  giving  some 
list  [i/)!,  4>z,  ...]  of  proof  states,  and  then  applies  tac2  to  each  of  these  states,  giving  as  output  the 
concatenation  of  the  sequences  tac2  (t/ii) ,  tac2(V'2)  »  •  •  •• 
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The  tactic  tael  OR£LSE  tac2  is  a  form  of  choice:  it  first  computes  tad  (0) .  If  this  is  non-empty, 
it  is  returned  as  the  result:  otherwise,  tac2  ((t>)  is  returned. 

The  tactic  REPEAT  tac  first  computes  tac(^).  If  this  is  non-empty,  then  the  tactics  recunively 
applies  itself  to  each  element,  concatenating  the  results.  Otherwise,  it  returns 

The  tactic  oepth_f'IRST  pred  tac  performs  a  depth-first  search  for  a  proof-state  satisfying  pred. 
Usually  peed  is  taken  to  be  “no  subgoals”,  so  that  the  tactic  will  search  for  a  proof  of  the  original  goal. 

To  show  the  powo’  of  tacticals,  we  do  our  example  proof  again  using  a  single  tactic; 

P-feQ  D(RD  P&R) 


~  goal  :.nz_Rule.zhy  "PiQ  — >  (R  — >  PsR) 

Level  0 

P  S  Q  — >  .R  — >  PsR 
1.  P  S  Q  — >  R  — >  P  S  R; 

'  by  (REPEAT 

(assume_-ac  1  ORELSE 

resolve_cac  (imp_intr,  conj_intr,  conjunct!)  D); 


Level  1 

PiQ  R  -->  PsR 
No  subqoals; 

Even  more  dramatic  is  the  built-in  tactic  fa3t_tac  which  is  powerful  enough  to  solve  a  large  class 
of  basic  goals  in  logic; 

-  goal  r.';t_Rule.  thy  "PsQ  — >  (R  — >  PsR) 

Level  0 

PiQ  -->  R  — >  ?  S  R 
1,  ?  S  Q  — >  R  -->  ?  S  R; 

-  by  ( fast_cac  (1  1 ) ; 

Level  1 

?  s  Q  -->  R  — >  PsR 
No  subgoals; 


6.1.8  Comments 

We  omit  here  a  discussion  of  how  new  object  logics  are  constructed  in  Isabelle;  this  is  by  far  the  most 
difficult  aspect  of  the  system.  In  the  next  chapter,  we  shall  show  how  simple  extension  of  an  existing 
theory  (such  as  Isabelle-HOL)  can  provide  us  with  a  program  verification  environment. 
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Chapter  7  PROGRAM  VERIFICATION  IN  ISABELLE 

7.1  Introduction 

In  this  chapter  we  shall  discuss  some  experiments  in  reasoning  about  programs  using  Isabelle. 

We  showed  in  Chapter  5  that  HOL  can  be  used  to  reason  about  denotational  semantics  definitions.  In 
principle,  we  could  use  Isabelle-HOL  (i.e.,  Isabelle's  object  logic  HOL)  in  the  same  way:  definitions 
can  be  set  up,  and  proof  steps  devised  exactly  as  was  done  for  the  HOL  system.  Rewriting  would  take 
care  of  a  U't  of  the  proof  steps.  The  advantage  of  using  Isabelle  in  this  way  would  be  the  possibility  of 
answer  extraction  (using  scheme  variables).  The  disadvantages  are  that  Isabelle  is  better  at  using  derived 
inference  rules  than  rewriting  with  definitions,  and  that  the  built-in  theories  provided  with  Isabelle  are 
not  as  extensive  as  tho.se  in  the  HOL  system. 

We  also  claimed  in  Chapter  5  that  HOL  was  not  as  well-suited  to  the  study  of  operational  semantics. 
In  contrast,  Isabelle  looks  ideal  for  this  purpose,  because  it  stresses  the  natural  deduction  style,  and 
works  well  with  derived  inference  rules.  If  we  regard  our  operational  semantics  as  the  rules  for  a  logic, 
then  we  can  quickly  constnict  powerful  proof  procedures  in  Isabelle  which  allow  reasoning  about  quite 
complicated  programs. 

For  the  above  reasons,  we  shall  concentrate  on  the  implementation  of  operational  semantics  in  Isabelle, 
using  as  working  examples  the  languages  FUNCl.  FUNC2  and  FUNC3  presented  in  Chapter  2.  Our 
aim  IS  to  automate  the  following: 

1.  Evaluation  of  phrases,  for  example 

E  F  let  X  =  7  in  x  —  '•)  =>70 

2.  Proofs  of  correctness,  for  example:  the  swap  routine 

{{x,a),(y,n)}  F  let  z  =  x;  x  =  y;  y  =  z  in  x  =>  b 
Reasoning  about  equivalence  of  program  phrases,  for  example 
let.  X  =  I  in  X  -b  2  =:  let  y  =  2  in  y  -(-  1 


7.2  The  Language  FUNCl 

How  can  we  implement  the  operational  semantics  for  FUNCl?  We  have  remarked  before  that  it  is 
difficult  to  set  up  new  object  logics  in  Isabelle  from  scratch.  The  easiest  way  to  proceed  is  to  extend 
an  existing  object  logic.  For  our  purposes,  we  shall  extend  the  theory  arith  (which  is  an  extension  of 
HOL)  to  a  new  theory  called  n_thy.  It  is  important  to  note  that  we  make  no  use  of  the  features  of  HOL, 
except  for  the  fact  that  it  is  a  typed  logic.  The  .semantic  domains  such  as  identifiers  and  values,  and  the 
various  kinds  of  language  phrase  (here  expressions  and  declarations),  are  then  regarded  as  HOL  types. 
We  could  equally  well  have  pictured  them  as  sets,  but  this  makes  things  more  complicated. 

We  shall  not  discuss  the  Isabelle  code  in  detail,  but  concentrate  on  the  essentials  (as  an  example,  the 
complete  source  code  for  the  larger  language  FUNC3  is  given  in  the  Appendix). 

7.2.1  Syntax  and  Semantics 

The  first  thing  to  be  done  is  to  capture  the  syntax  of  the  language.  We  do  this  by  means  of  a  number 
of  inference  rules: 

va 1  f l_t  hy  = 

•?xcend_cheory  arich_thy  “fl"  ... 
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1  ( ''Const_^ype" , 

"n  :  nat  ^=>  Const  (n)  :  expr"), 

("Var_type", 

"X  ;  ide  ==>  Var  (x)  :  expr"), 

("Plus_cype", 

"[I  el  :  expr;  e2  :  expr  !]  ==> 

Plus  (el,e2)  :  expr"), 

("Let_cype", 

"(I  d  ;  decl;  e  :  expr  I]  ==> 

Let  (d,e)  :  expr"), 

("Val_type", 

"[I  X  :  ide;  e  :  expr  1)  ==> 

Val  (x,e)  :  decl"), 

( "Comp_type" , 

"[I  dl  :  decl;  d2  :  decl  li  ==> 

Comp  (dl,  d2)  :  decl"), 

("empty_type", 

"empty  :  env"), 

{ "bind_type", 

"(I  E  ;  env;  x  :  ide;  v  ;  value  (1  ==> 
bind  (X,  V,  E)  :  env") 

( "  looicupl_rule", 

"!i  E  ;  env;  x  ;  ide;  n  ;  nat  1)  ==> 
lookup  (X,  bind  (x,  n,  E),  n) "  ), 

("lookup2_rule", 

"II  £  ;  env;  x  ;  ide;  y  :  ide;  v  :  value  ; 

V  :  value;  ' (y  =  x  :  ide);  lookup  (x,  E,  n)  I] 

=  =  >  lookup  (X,  bind  (y,  w,  E) ,  n) "  ) 

("comi)ine_empty", 

"E  ;  env  ==>  combine  (E,  empty,  E)“), 

( "combine_bind", 

"l!  El  :  env;  E2  :  env;  E3  :  env;  x  :  ide;  a  :  value;\ 
\  combine  (E1,E2,E3)  ! i  ==>  \ 

\  combine  (El,  oind (x, a, E2) ,  bind  (x,a,E3))"), 


These  rules  are  very  simple.  For  example,  Plus_type  expresses  the  fact  that  if  ei  and  62  are 
expressions,  then  Plus  (ei,  €2)  is  also  an  expression.  The  constructor  Plus  conesponds  to  the 
symbol  “-f-”  in  our  language.  Similar  rules  will  hold  for  every  other  program  phrase. 

Environments  need  a  little  thought.  We  could  implement  an  environment  as  any  one  of  the  following: 

1.  as  a  primitive  type,  augmented  by  axioms  for  a  constructor  function; 

2.  as  a  lambda-expression  in  HOL;  or 

3.  as  a  list  of  pairs  of  type  (expr,value) 

The  first  approach  was  chosen  because  it  reduces  the  dependency  on  the  host  object  logic  HOL  to  a 

minimum,  and  because  it  makes  us  assert  as  axioms  exactly  those  inference  rules  needed  to  reason  about 

environments.  These  rules  ate  the  last  six  given  above.  Th^  assert  the  existence  of  a  special  environment 

called  empty  and  a  constructor  function  called  bind.  The  lookup  rules  tell  us  how  to  look  up  values  in 

the  environment  The  last  two  rules  tell  us  all  we  need  to  know  about  combining  environments,  where  ) 

combine(E£’JE”)  is  a  predicate  which  holds  if  E^sEE'. 

The  next  step  is  to  write  down  the  rules  of  the  operational  semantics.  In  writing  these  rules,  we  render 
E  h  e  =>  V  as  seq(E,e,v),  and  E  F  d  ^  E'  as  seq’(E4£’)'  Here  seq  is  read  as  “sequent”.  We  give  just 
the  first  three  rules; 

("Consc_rule",  ^ 

"(IE:  env;  n  :  nat  t 1  »«> 
seq  (E,  Const  (n) ,  n)"  ), 
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Once  this  has  been  done,  we  have  the  following  lists  of  inference  rules  summarising  the  syntax  and 
semantics  of  the  language: 


Table  1 1  Inference  Rules:  Syntax  and  Semantics 


Name 

Description 

type  .rules 

inference  rules  capturing  the  syntax 

lookup.rules 

inference  rules  for  bind 

combi  ne.rules 

inference  rules  for  combine 

expr.rules 

inference  rules  for  expressions 

decl.rules 

inference  rules  for  declarations 

lang_rules 

expr.rules  @  decl.rules 

common.asms 

trivial  assumptions  taken  for  granted,  such  as:  x  : 
ide,  y  :  ide 
m  :  nat,  n  :  nat 
e  :  expr 

E  :  env 

7.2.2  Proof  Procedures 

Tlie  construction  of  tactics  to  reason  about  programs  in  FUNCl  is  quite  straightforward.  The  basic 
strategy  is  tt)  keep  resolving  on  sequents  (and  attempting  to  reduce  complex  environments)  until  none 
remain,  and  then  to  apply  the  trivial  type  rules  and  common  assumptions  to  finish  off  the  proof.  The 
only  thing  we  need  to  be  careful  about  is  not  to  resolve  any  .sequent  of  the  form  seq  (E,  ?e,  v),in 
which  there  is  a  scheme  variable  holding  the  place  of  an  expression.  Let  us  call  such  a  sequent  nnsa/e. 
If  we  were  to  resolve  this  sequent  using  the  language  rules,  we  would  get  multiple  outcomes,  and  the 
proof  effort  will  be  wasted  following  wrong  leads.  Our  method  of  getting  over  this  is  to  define 

FIRSTONLY  :  (term—  >  bool)—  >  (int-  >  tactic)—  >  tactic 

to  he  a  function  which  chouses  the  first  subgoal  for  which  a  given  selector  function  is  true,  and  applies  the 
given  tactic,  failing  otherwi.se.  Using  this  function,  along  with  the  selector  function  is_saf  e_sequent, 
which  is  tnie  when  the  sequent  is  safe  and  false  if  not,  we  can  define  step_tac,  which  is  the  primitive 
proof  step  to  remove  language  sequents.  Our  all-purpose  tactic  is  fl_tac. 


■-’I-  1 sc  = 

1 . ic  ',’RELSE  'r’j[nbina_cac  : 

FIRSTONLY  i3_safe_sequenc  (resolve_cac  lang_rules) ; 
val  lang_tac  = 

REPEAT!  (scep_cac  THEN  TRY  (REPEATl  reduce_tac) ) ; 
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val  simp_tac  = 

REPEAT  (ares_"ac  simp_rules  1); 

val  fl_tac  =  lang_tac  THEN  simp_tac; 

As  an  example,  consider  the  proof  of: 

E  I-  let  y  =  m  in  let  X  =  y  in  let  y  =  n  in  X  ^  m 
We  set  the  goal  with  a  scheme  variable  in  place  of  the  answo*.  and  use  our  tactic  fl_tac: 

goal  fl_thy 

"seq  (E,  Let (Val (y, Const (const (m) )) , 

Let (Val (X, Var (y) ) , 

Let(Val(y,Const(const(n))),Var(x)))),  ?a)”; 
by  fl_tac; 

Level  1 

seq (E, Let (Val (y, Const (const (m) ) ) , 

Let (Val (X, Var (y ) ) , 

Let(Val (y,Const( const (n) ) ) ,Var(x) ) ) ), 
val (const (m) ) ) 

No  subqoalsl 

Notice  that  Isabelle  has  obligingly  given  us  the  result  of  the  evaluation,  as  well  as  proving  the  goal! 

Our  second  example  is  the  swap  routine  using  a  temporary  variable: 

{(x,  a),  (y,  b)}  I-  let  z  =  x;  X  =  y:  y  =  2  in  X  ^  b 

goal  fl_tby 

"seq  (bind  (x, a, bind (y, b, empty) ) , 

Let  (Comp  (Val  (z,  Var(x)), 

Comp (Val (x,  Var(y)), 

Val(y,  Var(z)))),  Vat(x)),  ?a)"; 
by  fl_tac; 

level  1 

seq (bind (X, a, bind (y, b, empty) ) , 

Let (Comp (Val (z, Var (x) ) , Comp (Val (x, Var (y) ) , 

Val (y, Var ( z ) ) ) ) , Var (X) ) , b) 

No  subqoals! 

7.3  The  Language  FUNC2 

Now  we  shall  consider  how  the  semantics  of  FUNC2  may  be  implemeniBd  in  Isabelle.  The  main  hurdle 
to  overcome  is  that  a  program  phrase  can  have  mace  than  one  rule  associated  with  it  For  example,  recall 
from  Giapter  2  that  there  are  two  rules  for  conditional  expressions: 

E 1-  ep  =»  true  E  I-  ci  ^  v 
E  1-  if  cp  then  ei  else  e^  ^  v 

E  t-  ep  =>  false  E 1-  ea  v 
E  I-  if  ep  then  e^  else  ep  ^  v 

(which  will  be  called  lfl_cule  and  If2_cule).  Consider  the  foUowinf  example: 

{(x,  a),  (y,  b)}  H  if  false  then  x  elae  y  ^  b 
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Suppose  we  try  to  prove  thus  starting  with  3tep_tac; 

-  goal  f2_t;hy 

"oeq  ibirid  'x,  a,  bind  (y,  b,  -itiptyi), 

I: I Const ; :f ) , Var (x) ,Var !y) ) ,  b) ' ; 

1  0 

s-^cjibir.d  (X,  a,  bind  (y,b,  empty)  ) ,  If  (Ccr.sc  (  f  f)  ,Var  (x). ,  Var  (y)  ;  ,  b) 

1 .  seqlbind  (X,  a,  bind  {y,b,  empty)  )  ,  If  (Const  (ff)  ,  Var  (x)  ,  Var  ■'•/ ;  !  ,b) 
val  it  =  [1  ;  thm  list 

-  by  3tep_cac; 

Level  1 

seqlbind  (x,  .-i,  bind  ly ,  b,  empty )  ) ,  If  (Const  (  f  f ) ,  Var  (x)  ,  Var  ry  i  ;  , 

1.  bindlx,  a,  bind(y,b,eir.ptyl  )  :  env 
j.  Const (ff)  :  expr 

2.  Var(x)  :  expr 

4.  Varly)  :  expr 

5.  seq{bind(x, a,bind(y,b,empty) ) ,Const( ff ) ,val (tt) ) 

€  .  seq  (bind  ;x,  a,  b^id  {y  ,  b, empty) )  ,  Var  (x)  ,b) 

val  J.t  =  T)  ;  unit-'-  —  - 

Notice  that  the  fifth  subgoal  is  asserting  that  false  evaluates  to  true  —  stepjac  has  chosen  the  wrong 
rule  (namely  lfl_rule)  to  resolve  on!  We  have  gone  down  a  “blind  alley”  in  the  proof. 


Failure 


No  Subgoals 


Failure 


To  solve  this  problein,  it  will  not  be  enough  to  reanange  the  older  of  the  language  rules  used  by  the 
resolution  tactic,  because  there  will  always  be  examples  for  which  the  wrong  rule  is  applied.  What  we 
need  to  do  is  use  backtracking  search.  The  appropriate  tactics  are 
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The  tactic  f2_cac  carries  out  a  depth-first  backtracking  search,  looking  for  a  proof  state  with  no 
suhec  .ls.  We  have  modified  lang_tac  so  that  it  will  fail  if  the  repeated  application  of  st6p_tac  and 
reduce_tac  leaves  behind  any  sequents.  If  we  do  not  do  this,  simp_tac  may  give  rise  to  infinite 
outcomes,  and  the  search  will  not  terminate. 

-  -jcal  :C_chy 

'■--•jq  Jbir.d  lx.  a,  bind  b,  empty)), 

I:  iC:rist  (  £f )  ,  Var  tx)  ,  Var  !y)  )  ,  b)  *  ; 

I-trV*?}. 

.;eq  ,  bind  t  :<,  ,  bindty ,  b,  e.T.pty )  )  ,  I  f  (Const  t  f  f )  ,  Var  (x)  ,  Var  (y  •  )  ,  b ; 

i.  seq  ■  bind  a ,  bind  :y ,  b,  empty )),  If  (Const  (  ff ),  Var  (;<),  Vai- b,,- ,  ,b. 


:  hir.d  >  bind  y ,  b,  empty )  >  ,  I  £  (Const  ( f  f )  ,  Var  (x)  ,  Var  ;  !  ,  b) 


W  .  I 


Our  tactic  is  able  to  cope  with  the  following  well-known  LISP  example,  in  which  x  is  used  both  as  a 
bound  and  free  variable: 


{(x,  n)}  H  let  (val  z  =  Af.Ax.f(f(x))); 

val  g  =  Af.(f,x  )  in  (z(g)  m)  ^  (m,  n),  n 


;cal  f-_thy 

'seq  (bind  !x,  a,  e.mpcyi,  \ 
let  (Comp  (Val  \ 

Fn  if,  Fn  !x.  Apply  (Varvf),  Apply (Var ( f) , Var i x) !)■ ) 
Val  ;q,  Fn  f.  ?r  :Var(f),  Var(x))))), 

•Apply  . Apply ; Var . z : ,  Var(g)),  Const (const (m) ))) ,  ?v! " 


l-'/el  . 

zeq (bind (X, a, empty; , 

let  (Cz'inp  ( Val  (z  ,  Fn  i  f ,  Fn  (x.  Apply  (Var  (  f )  ,  Apply  (Var  (  f )  ,  Var  ( xi  )  :■  ;  i  !  , 
Val'g,Fn(£,?r(Var{f),Var(x) ) ) ) ) , 

Apply (Apply (Var (z! ,Var (g) ) .Const (const (m) ) ) ) , 
pair (pair (val (const (m) ), a) , a) ) 

Me  subgoals! 

val  it  =  { )  :  unit 

The  proof  took  only  75  seconds,  including  a  garbage  collection,  which  compares  extremely  well  with 
the  HOL  system. 
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7.4  The  Language  FUNC3 

The  extension  to  FUNC3  is  not  difficult  We  need  to  give  function  closures  a  founh  aiguinent  as 
described  in  Chapter  2.  We  also  need  to  add  inference  rules  for  the  unfolding  operation  on  environinents. 
To  control  the  search,  it  also  becomes  necessary  to  make  tactics  such  as  loo)cup_tac,  coinbine_tac 
and  unf  old_tac  safer,  in  that  they  are  forc^  to  fail  if  the  environment  being  examined  contains  too 
many  scheme  variables. 

Isabelle  correctly  evaluates  the  resulting  envitonmettt  for  the  standard  definition  of  the  factorial  function: 

E  t-  rec(vaLl  f  =  Ax.if(x  =  0)  then  x  ♦  f(x  —  1)) 

Work  on  this  language  is  continuing,  and  we  shall  not  give  any  other  detailed  examples  here. 

7.5  The  Language  IMPl 

Implementing  operational  semantics  for  imperative  languages  is  just  as  straightforward.  Earlier,  we 
described  part  of  the  operational  semantics  for  the  language  IMPl.  The  language  has  been  fully 
implement^  in  Isabelle  (with  environments  present  as  place-holders  to  allow  for  the  evennial  addition  of 
local  scoping)  and  some  non-trivial  proofs  carried  out  A  translator  has  also  been  built  to  allow  programs 
to  be  written  in  a  simple  syntax. 

For  example,  consider  the  following  program  containing  a  while  loop: 

E  I-  X  .=  0;  while  (x  <=  0)  x  :=  x  -F  1,  M  =>?M 
Isabelle  proves  this  rather  quickly,  and  extracts  the  answer  (the  resulting  memory); 

-  goal  il _t.hy 

"seq' (E,  Comp  (Assign  (x,  Const  (0)), 

While  (Less_equais  (Var  (x).  Const  (0)), 

Assign  (x,  Plus  (Var  (x)  ,  Const  (Succ  (0) )  )  )  )  )  ,  M,  ?M) 

seq'  (£,  Comp (Assign (x, Const  (0) ) , 

While (Less_equals (Var (x) , Const (0) ) , 

Assign (x, Plus (Var (x) ,  Const (Succ (0) ))))), M, 

-pdate (x, constant (0  #+  Succ (0) ), update (x, constant (0) ,M) ) ) 

No  sucgoaisl 

vai  it  =  ()  :  unit 

Some  arithmetic  is  required  to  proof  programs  such  as  these  correct,  and  Isabelle  has  at  the  moment 
only  limited  support  for  arithmetic.  Despite  this,  I  believe  that  Isabelle  is  a  powerful  and  natural  tool 
for  the  study  of  operational  semantics. 
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Chapter  8  DISCUSSION  AND  CONCLUSIONS 

Our  work  has  highlighted  some  of  the  advantages  and  disadvantages  of  using  the  automated  theorem 
provers  HOL  and  Isabelle  for  the  study  of  language  semantics  and  program  verification.  We  begin  with 
some  specific  comments  on  the  HOL  system. 


8.1  Comments  on  HOL 

8.1.1  Ease  «>f  Use 

HOL  is  certainly  a  difficult  system  for  a  beginner  to  learn.  The  large  number  of  theorems  available,  as 
well  as  the  fine-grained  nature  of  most  of  the  inference  rules  and  tactics,  means  that  the  new  user  must 
invest  considerable  time  and  effort  in  before  even  simple  proofs  can  be  attempted.  The  first  taste  of 
HOL  can  be  quite  frustrating,  especially  without  a  HOL  “expert "  to  be  a  guide.  There  are  a  number  of 
program  verification/theorem  proving  environments  —  such  as  mEVES  ,  Gypsy  and  MALPAS  —  which 
are  simpler,  and  whose  proof  commands  may  even  be  more  powerful.  However,  these  systems  are  not 
flexible.  Once  the  user  gains  familiarity  with  HOL,  its  expressive  power  and  flexibility  becomes  more 
and  more  apparent.  I  believe  that  HOL  is  an  invaluable  tool  — not  just  as  a  proof  assistant,  but  as  an 
aid  to  the  clean  formulation  of  mathematical  theories. 

8.1.2  Expressiveness 

Higher  order  logic  is  a  large  and  powerful  logic:  because  it  is  higher  order  and  polymorphic,  it  is  expressive 
enough  to  be  able  to  capture  the  most  sophisticated  mathematical  theories.  It  allows  denotationai  semantics 
definitions  to  be  expressed  in  a  natural  and  succinct  way.  Also,  the  soundness  and  level  of  mathematical 
rigour  of  the  HOL  system  give  us  a  high  level  of  confidence  in  the  proofs  which  it  generates. 

Reasoning  about  prtigrams  requires  some  fairly  .subtle  mathematical  techniques.  The  built-in  inference 
rules  and  tactics  t'f  HOL  ;tre  of  a  fine-grained  nature,  providing  the  user  with  a  flexibility  not  available  in 
many  other  automated  reasoning  systems.  If  a  theorem  or  goal  does  not  exactly  fit  the  form  required  by 
a  built-in  tactic  or  inference  nile.  it  is  possible  to  carry  out  quite  delicate  manipulation  until  the  required 
form  is  achieved. 

8.1.3  Documentation 

The  new  documentation  which  has  appeared  with  the  release  of  HOL88  makes  it  possible  for  a  user 
w  orking  alone  to  make  a  lot  of  headway  in  understanding  the  system,  and  how  to  construct  proofs.  The 
manuals  [22]  are  well-written  and  informative;  clearly  much  care  has  gone  into  their  production.  The 
document  called  DESCRIPTION  is  a  good  overview.  The  TUTORIAL  has  excellent  sections  on  parity 
checking,  protocol  verification  and  modular  arithmetic,  but  I  think  could  benefit  from  having  many  more 
short  examples.  I  believe  that  the  case  study  by  Jeff  Joyce  on  Microprocessor  Systems  is  a  fine  piece  of 
work,  but  seems  out  of  place  in  a  tutorial.  There  is  rather  too  much  emphasis  on  hardware  verification 
tthough  this  is  natural,  given  the  interest  of  the  Cambridge  group  in  this  area).  The  REFERENCE  manual 
is  still  incomplete,  but  will  be  greatly  improved  in  the  near  future.  It  would  be  useful  to  have  the  tactics 
listed  by  type  (as  well  as  alphabetically). 

8.1.4  Tadics 

The  HOL  system's  expressiveness  is  especially  apparent  in  the  way  that  new  tactics  can  be  programmed, 
either  in  the  meta-language  ML  or  by  ihe  use  of  tacticals.  These  tactics  can  be  specially  tailored  for  the 
problem  domain  being  studied.  Our  aim  in  verifying  programs  was  to  derive  tactics  which  capture  proof 
procedures  as  general  us  possible,  without  sacrificing  efficiency  or  clarity. 

There  are  by  now  a  large  number  of  useftil  new  tactics  (especially  in  the  group  theory  library). 

On  the  debit  side,  there  are  a  number  of  points  to  make.  Most  seriously,  the  treatment  of  tactics  does 
not  compare  well  with  Isabelle.  In  HOL,  a  tactic  either  fails,  or  gives  a  single  outcome,  in  contrast  with 
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Isabelle,  where  multiple  outcomes  are  common.  Backtracking  is  not  possible  within  HOL.  There  is  also 
no  mechanism  for  carrying  out  answer  extraction  (which  is  handled  in  Isabelle  by  scheme  variables). 
This  is  a  pity;  answer  extraction  is  very  useful  for  reasoning  about  programs. 

Much  proof  hacking  is  involved  with  manipulating  a  large  number  of  assumptions,  and  carrying  out  such 
operations  as  rewriting  them  against  each  other  or  with  given  theorems.  The  built-in  tactics  such  as 
POP_ASSUM  and  related  tactics  are  not  easy  to  work  with,  while  the  tactic  RES.TAC  seems  to  be  quite 
limited  in  its  power  to  solve  goals  if  the  assumptions  ate  not  in  a  very  specific  form.  Thoe  is  clearly  a 
need  for  a  range  of  fine .grained  tactics  for  rewriting  assumptions,  and  manipulating  them  in  general.  An 
experimental  set  of  such  tactics  has  been  developed  by  Katherine  Eastaughffe  at  DSTO.  Although  it  is 
not  difficult  to  write  such  tactics,  it  is  time-consuming;  such  tactics  should  already  be  part  of  the  system. 

I  think  that  HOL  will  only  become  really  useful  to  a  large  number  of  people  if  the  collection  of  tactics 
is  completely  overhauled.  Presently  there  is  a  bewildering  variety  of  tactics,  with  all  sorts  of  odd  names, 
some  of  which  are  high-powered  useful  tactics  (such  as  REWRITC.TAC  and  its  relatives),  and  others  of 
which  are  highly  specific  "proof  hacking”  tactics  writtoi  to  solve  a  particular  problem  but  not  of  general 
applicability.  I  think  that  it  would  be  valuable  to  spell  out  some  consistent  naming  conventions  for  tactics 
which  people  should  try  to  stick  to  (a  kind  of  allowed  syntax  for  names),  such  as  the  prefixes  ONCE, 
PURE  etc.  At  the  moment  (to  take  a  trivial  example)  we  have  ASM_REWR1TE_TA  C  and  POP.ASSUM, 
with  different  abbreviations  used.  Also,  some  older  tactics  will  have  been  superseded  by  newer,  more 
useful  ones,  and  they  should  be  deleted.^ 

8.1J  Proof  Management 

The  subgoal  package  allows  great  flexibility  in  the  way  theorems  are  proved.  HOL  can  be  used 
interactively  (as  a  proof  assistant)  to  develop  proofs  step  by  step.  We  can  also  use  it  as  a  proof  checker  by 
providing  HOL  with  a  complete  proof  and  seeing  whether  HOL  produces  the  required  theorem  as  ouqxit. 

There  are  problems  with  HOL's  proof  management  Proofs  do  not  always  look  very  ’natural*.  Medium¬ 
sized  to  large-proofs  can  be  quite  laborious  and  time-consuming  to  construct  involving  a  good  deal  of 
proof  ’exploration*.  Often,  a  vast  number  of  cases  must  be  considered,  and  one  then  has  the  choice  of 
defining  a  different  tactic  for  each  subgoal,  or  else  using  a  single  tactic  as  a  blunt  instrument  on  all  the 
subgoals.  Using  a  single  tactic  can  improve  the  readability  of  the  proof,  but  can  be  quite  inefficient  — 
some  proofs  can  take  several  minutes,  or  even  houn,  of  computation. 

8.1.6  Instantiation  of  IVpes  from  Parent  Theories 

One  of  the  most  serious  difficulties  with  HOL  is  that  theories  ate  inherited  en  bloc,  and  cannot  be 
instantiated  to  specific  instances.  Essentially,  what  is  needed  is  a  mechanism  for  the  refinement  of  types. 
For  example:  one  might  have  a  type  (say  ‘colour’)  declared  in  a  particular  theory,  and  prove  various 
things  about  it  at  a  general  level.  Suppose  then  that  we  have  a  descendant  of  this  theory,  in  which  we 
want  to  instantiate  this  type  to  be  (say)  an  enumerated  type  of  the  form  (red,  white,  blue).  Presently  this 
cannot  be  done  in  HOL,  but  it  seems  essential  to  have  such  a  facility  if  HOL  is  to  become  really  useful, 
especially  in  reasoning  about  mathematical  theories  which  depend  on  some  higher  level  abstract  theory 
for  many  results.  The  theory  of  modular  arithmetic,  where  group  theory  is  used  to  prove  flacts  about 
abelian  subgroup  of  the  integen,  is  a  case  in  point  It  has  been  studied  by  Elsa  Gunter  in  the  TUTORIAL 
[22].  She  avoids  the  problem  by  defining  predicaies  such  as  GROUP,  SUBGROUP  and  NORMAL  fw 
arbitrary  sets.  Saying  that  a  given  set  of  integers  is  a  subgroup,  say,  of  the  integers,  announis  to  saying 
that  this  predicate  holds  for  this  set  However,  this  method  can  be  cumbersome  in  practice.  Gunter  has 
suggested  an  extension  to  HOL[28]  in  which  theories  can  be  instantiated,  but  the  suggested  enhanconents 
are  not  widely  accepted,  and  have  not  been  implemented. 

8.1.7  The  Type  Package 

Tom  Melham’s  type  package  is  extremely  useful:  has  taken  a  lot  of  the  dnidgery  out  of  working  with 
new  compound  dua  types  in  the  style  of  ML  recursive  data  types.  However,  the  current  package  does 
have  some  limitations: 

*  Vuiim  1.12  ot  HOL  isaiiiii  ton,  hmwi  «U,  of  Siwt  ctWciw, 
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1.  It  does  not  allow  the  definition  of  mutually  recursive  data  types^. 

2.  It  does  not  allow  the  most  general  kind  of  recursive  type  (for  example,  one  cannot  define  a 
recursive  domain  of  values  V  such  as 

V  =  B  +  (V  — V) 

in  which  functions  from  V  to  itself  are  "first-class  objects”,  and  can  themselves  be  values. 
(Of  course,  we  would  not  expect  it  to  be  easy  to  define  such  a  domain!) 

3.  As  for  recursive  functions,  the  only  ones  allowed  are  those  which  are  recursive  purely  on  one 
of  their  arguments.  This  is  quite  restrictive:  it  does  not  allow  functions  which  are  doubly 
recitrsive,  or  functions  like 

gcd  xy  =  (x  =  y  —  xD  (x<y  —  gcd  x  y  -  x  □  gcd  x  -  y  y)) 

where  the  function  is  recursive  on  Ix-yl. 

4.  Infix  constructors  are  not  allowed. 

Clearly,  formulating  HOL  theories  which  capture  the  formal  semantics  of  programming  languages  will 
be  much  easier  if  the  type  package  could  be  extended  to  cope  with  the  above  constructs.® 

8.2  Comments  on  Isabelle 

Our  comments  on  Isabelle  will  necessarily  be  brief,  because  many  have  already  been  touched  upon,  and 
because  most  of  the  comments  about  the  strengths  of  HOL  apply  equally  well  to  Isabelle. 

8.2.1  Ease  of  Use 

Isabelle  is  much  harder  to  learn  than  HOL.  particularly  because  one  must  contend  with  a  number  of 
object  logics.  Writing  new  logics  from  scratch  is  quite  difficult  to  grasp.  However,  generally  Isabelle  is 
a  cleaner,  more  elegant  and  faster  system  than  HOL  (NB:  new  versions  of  HOL  built  on  standard  ML 
should  not  sutfer  from  this  comparison). 

8.2.2  Object  Logics  and  Theories 

Isabelle  is  flexible  in  allowing  a  number  of  object  logics,  unlike  the  HOL  system,  in  which  the  logic 
IS  fixed.  There  is,  too,  more  flexibility  in  the  ability  to  use  more  than  one  theory  in  a  single  session. 
Theories  can  be  passed  as  arguments  to  various  functions.  Definitions  can  be  overwritten  in  Isabelle 
theories',  in  HOL,  however,  one  must  quit  and  start  again. 

Isabelle's  version  of  higher  order  logic  is  more  cumbersome  to  use  than  the  version  present  in  the  HOL 
system.  Support  for  basic  arithmetic  is  provided  in  Isabelle,  but  it  is  not  as  extensive  as  that  in  HOL. 

Isabelle  does  not  have  anything  equivalent  to  HOL’s  type  definition  package. 

8.2.3  Libraries 

Isabelle  has  as  yet  a  modest  collection  of  libraries,  compared  to  those  available  in  HOL.  The  main  reason 
is  that  Isabelle  does  not  yet  have  a  large  enough  user  base. 


8.2.4  Tactics 

Isabelle  has  ftill  high-order  unification  (unlike  HOL).  Tactics  can  have  more  than  one  outcome.  Back¬ 
tracking  and  search  are  possible,  and  allow  the  construction  of  very  powerful  proof  procedures.  Scheme 
variables  permit  answer  extraction  in  proofs  —  this  is  very  useful. 

Isabelle's  meta-logic  allows  inference  rules  to  be  expressed  and  reasoning  about  them  to  be  done  in  a 
uniform  manner.  This  is  made  easy  by  a  single  tactic  which  carries  out  resolution  in  the  meta-logic. 
However,  in  HOL,  which  has  no  meta-logic,  one  must  write  a  new  tactic  for  each  new  inference  rule. 

’  A  package  wriiiea  by  a  group  at  Aartiui  Jaai  lUow  for  iminially  racuttiva  lypu. 

*  Tlie  type  package  lias  been  .sligliUy  improveil  in  Venioa  1.12  of  HOL. 
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83  Suggestions  for  Further  Work 

The  work  on  implementing  denotational  semantics  for  imperative  languages  described  in  this  paper  can 
be  extended  in  a  number  of  ways.  Maris  Ozols  and  the  author  have  constructed  a  HOL  system  for 
reasoning  about  a  small  imperative  language  [29].  Programs  written  using  a  simple,  syntax  are  translated 
(along  with  specifications,  if  any)  into  HOL  terms  using  a  yacc*generated  translator.  Special  purpose 
tactics  allow  interactive  reasoning  about  programs,  essentially  using  symbolic  execution.  A  good  deal  of 
careful  theorem  proving  is  required  for  while  loops  in  the  system. 

The  work  on  operational  semantics  in  Isabelle  suggests  a  number  of  extensions,  for  example  the  study  of 

1.  typed  languages  such  as  ML  (with  type  inferencing) 

2.  imperative  languages  (study  already  tegun) 

3.  process  algebras  such  as  Milner’s  Calculus  of  Communicating  Systems  (CCS)  (an  initial 
study  begun) 

A  proof  system  for  a  significant  subset  of  the  Core  language  of  Standard  ML  has  been  constructed  by 
M  Ozols  and  the  author  [30].  For  future  work,  I  believe  that  the  study  of  process  algebras  offers  the 
most  challenge  and  will  be  the  most  rewarding;  understanding  concurrency  remains  a  most  difficult  and 
long-term  goal  of  computer  science. 
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APPENDIX  A 

Example:  Denotational  Semantics  in  HOL 


%  - % 

%  Implementation  of  Denotational  % 

%  Semantics  for  a  simple  Imperative  Language  % 

%  FILE:  impl.ml  % 

%  % 

%  see:  Denotational  Semantics,  by  D  Schmidt  p  76  % 

%  -  ^ 

system  'rm  impl.th';; 


new_theory  'impl';; 

map  p.ew_parent  ['string';  'digit '; 'decimal ; 
map  loadf  [ 'starC_groups ';  'st ring_rules ' 1 ; ; 
ioadf  ' /pacicages /hoi /sun3/ tactics/ local /odd *;  ; 
loadf  '/pac'sages/hol /sun3/tact ics/ locai/asm ; 


%  -  % 

%  Definitions  of  Semantic  Algebras  % 

%  and  Basic  Operations  % 

t  - 1 -  % 

% - t 

%  Identifiers  % 

%  -  t 

new_type_abbrev  ('Identifier',  string") ; ; 

%  — - - - -  % 

%  Numiers  (a  lifted  domain)  % 

%  Note:  Truth  Values  should  be  lifted  too  but  they  are  not  % 

% - t 


let  Nu.Tiber_Axiom  =  define_type  'Number' 

'Number  =■  number  num  undef_num ; 

*et  Number_Induct  =  prove_induct ion_thm  Number_Axiom; ; 

3ave_thm.  ( 'Number_one_one  ' ,  prove_constructors_one_one  Number_Axiom)  ; ; 

save_thm  ( 'Number_distinct ',  prove_constructors_distlnct  Number_Axiom) ; ; 

save_thm  ( 'Number_cases ' ,  prove_cases_thm  Number_Induct ) ; ; 

let  IS_N1)MBER_DEF  =  new_cecurslve_detinition  false  Number_Axiom 
'IS_NUMBER_3EF ' 

''(is_number  (number  n)  =  T)  /\ 

(is_number  undef_num  =  F) 

let  IS_UNDEFINED  DEF-  new_recursive_def inition  false  Number_Axiom 
'IS_UNDEFINED_DEF' 

" (is_unde£ined  (number  n)  »  F)  /\ 

( is_unde fined  undef_num  =  T) 

Let  GET_NUM_DEF  •  new_recursive_de£inttton  false  Number_Axiom 
'GET_NUM_DEF ’ 

" (get_num  (number  n)  -  n)  /\ 

(get_num  undef_num  »  0) 


t  -  %  ; 

%  The  Store  -  includes  an  "undefined*  or  "error"  element  %  , 

% - - - %  I 


let  Store_Axlom  •  define_type  'Store'  i 

'Store  •  store  (Identifier->Numbor)  I  undef  store’;; 

I 

let  Store_Induct  •  prove_induction_thm  Store_Axiom;; 

let  Store_one_one  ■  | 

save_thm  ( ’Store_one_one ',  prove_constructors_one_one  Store_Axiom) ; ;  J  * 

let  Storo_distlnct  «  i 

save_thffl  ( 'Store_dlstlnct ',  prove_consCructor*_dt>tlnct  Stora_Axlom) ; ;  I 
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.,'.»v^_;h.n  I,  •.'jr.orB_'.-j»s<ia' ,  prov«_caa«s_thm  2Cor*_In4ui;Ct  ; 

■  :-^_;AJE:;_TAC  c  =  DI3J_CAS£S_THEN 

3TRI P_A£SOME_TAC  (SPEC  C  Score_ca3eS)  THE;: 
(ASM_rdjrite_TAC  [store.dUclncc) )  ;  ; 

.  :iEW.;-:Ri_DEF  =  n«w_ie£inltion  s 'IIEWSTORE_DEF' , 

■  =  score  ( \1 .  indef_num)  • ) ;  ; 

'.■-■r.  ACCE.;3_DEF  =  new_recursive_.’.ef Inlclon  false  3tore_Axiom 
■ AOCESE.DEF' 

■iacsess  i  iscore  s)  =  s  i)  /  \ 

.Hcoess  i  ■indef_score  =  undef_num|  • ; ; 

'.•t’r'ATE_C'EF  =  riew_reoi,Lr3ive_ lef Inlclon  false  Store_Axlom 
■^:?DATE_EEF' 

' ''ipclace  i  v  (score  rn)  =  score  '\j.(j  =  l)  =>  v  I  m  j)) 

•  iipdace  i  v  ’inde£_score  =  nndef_stor9)  • ;  ; 


tf  H  score  is  proper.  e.*ien  -ipdacincr  ic 
never  leads  co  an  '.indefined  score 


leC  LEMMA  1  =  p.'OVe_Chm  ('LEMMAl-, 

• :  3. '  {.•■*i!ndef_3Core)  ==>  '(updace  1  v  s  =  imdef_3Cor6) ' , 

3EM_TAC  then  3TP.I?_TAC  THEM 

3Core_CA3ES_TAC  "S: Score"  THEN 

?EWRITE_TAC  !rjFrATE_CEF;  3core_discincc ]  THEN 

tp:v:al_tac)  ; 

ItC  LEMMAS  =  prove_chci  ('LEMMAS', 

'  ■■(  '.pdac,?  i  V  ne'.^scvr-e- =■  vr.d'.lsf_score)  • , 

AJSL'M’E_TAC  '.(PEC  " sc.J'f e ( ',  i ;  Zdencl fler .  ’andef_nuffl)  •  LEMMAl)  THEM 
A.JS’.'ME_TA.'  ;s?EC  " '  i  :  Idencif  ier .  'indef_num’  Score_discincc)  THE: 
THc.I’I 

.As:-!_FE'.'-'P.ITE_TAC  [ME'.'JSTORE.SEFl )  ;  : 


. i 

S'/ncax  of  Che  Language  % 

_ _ _ % 


lec  E;<pre3sion_Axicm  i  de£ine_C'/pe  'Expression' 

Expression  =  Consc  Number  I 

Var  Idencifier  I 

Plus  Expression  Expression';; 

lec  Expression_Induc'.  =  prove_induccitin_chm  Expre3slon_Axiom;  ; 

.;ave_clam  (  '  Expresslon_cne_ one  '  . 

prove_.'onscsuccots_  jne_one  Expresslon_Axlom)  :; 

.■ave_ch,'i;  1  '  £xpre3sion_  liscincc  '  . 

prove_conscruccors_di3clncc  Expresslon_Axiom) ; ; 

s.ave_chm  (  '  Expression_cases  ' , 

prove_cases_chm  Expression_:nducc) ; ; 

BExpres3ion_Axlom  =  lefine_cype  'BExpresalon' 

■  SExpre.ssion  i 

True  ( 

False  I 

Ecjuals  Expression  Expression  I 
Moc  BExpresslon' ; ; 

Lec  BExpiesulon_Inducr.  s  prove_inducclon_Chm  BExpre3Slon_AxioiT'.;  ; 

save_r,hm  ( '  BExpre3slon_one_one ' , 

prove_conscruccor3_one_one  BExpression_Axiom) ii 

save_ch!n  ( 'BExpresslon_dlscincc' , 
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prove_constructors_distirct  3Expression_Axior.i  ; ; 

save_thm  ( '3Expression_eases 

prove_oases_ch.'n  BExpression_Induct ) ;  ; 

let  Command_Axiom  =  define_type  'Command* 

'Command  =  Skip  I 

'i^al  Idencifler  Expression  I 
If  BExpresslon  Command  Command  I 
While  BExpresslon  Command  I 
Seq  Command  Command  I 
Diverge*  ;; 

let  Command_Induct  =  prove_inducCion_chm  Command_Axiom; ; 

save_thm  ( 'Command_one_one*, 

prove_conscructors_one_one  Command_Axiom) ; ; 

save_thm  ( 'Command_distinot *, 

prove_con.scructors_discinct  Command_Axiom)  ;; 

save_thm  ( 'Command_cases * , 

prove_oases_thm  Cammand_Induct ) ;; 

n.ew_type_abbrev  ('Program*,  Command") ; ; 


let  SEQL^DEF  *  new_list_rec  definition  (*SEQL_DEF*, 

" (Seql  [1  =  Skip)  /\ 

(Seql  (CONS  command  sequence)  =  Seq  command  (Seql  sequence))");; 

%  — . - - -  % 

%  Fixed  Point  Combinator  % 

% - - % 


n.ew_constant  ('FIX',  ".•(•->')->•");; 

let  f:x_£Q  =  new_axiom  ('f:x_£Q',  ";f:*->».FIX  f  •  f  (FIX  f)");; 


i  . - . . .  % 

i  Semantic  Equations  % 

k - - - -  I 


-et  £X?R  DEF  =  new_recursive_def inition  false  Expression  Axiom 

'expr'def' 

" (EXPR  (Const  V)  s  =  ( (s  =  undef_stote)  «>  undef_num  I  v) )  /\ 

(EXPR  (Var  i)  s  -  access  i  s)  /\ 

(EXPR  (Plus  el  e2)  s  = 

(is_nuTl>er  (EXPR  el  s)  /\  is_number  (EXPR  e2  s) ) 

=  >  -urioer  (qet_num  (EXPR  el  s)  *•  get_num  (EXPR  e2  s) )  I  undef_num) "; ; 

let  300L_EXPR_OEF  -  new_recursive_def inition  false  BExpression_Axiom 
'300t._EXPB_DEF' 

"(BOOL_EXPR  True  s  -  T)  /\ 

(BOOL_EXPR  False  s  -  F)  /\ 

(BOOL_EXPR  (Equals  el  e2)  s  >  (EXPR  el  s  «  EXPR  e2  s) )  /\ 

(3C0L_EXPR  (Not  b)  s  »  ' (BOOL_EXPR  b  s))";; 

%  NB:  the  function  COMMAND  is  strict  in  its  store  argument  % 

-et  COMMAND  DEF  -  new_recursive_dcf inition  false  Command_Axiom 
'CCMMAND~DEF ' 

"(COMMAND  Skip  s  -  s)  /\ 

(COMMAND  (Val  I  e)  s  - 

(s  •  undef  store)  ->  undef  store  I  update  I  (EXPR  e  s)  s)  /\  ' 

(COMMAND  (If  b  cl  c2)  s  -  “  ")  [ 

(s  •  undef  store)  >>  undef  store  ( 

((BOOL  EXPR  b  s)  ->  (COMMAND  cl  s)  I  (COMMAND  c2  s) ) )  /\ 

(COMMAND  (While  b  c)  s- 

FIX  (\f  t.(BOOL  EXPR  b  t  ->  f  (COMMAND  c  t)  I  t) )  s)  /\ 

(COMMAND  (Seq  cl  e2)  s  • 

(s  •  undef_store)  >>  undef_store  )  COMMAND  c2  (COMMAND  cl  s))  /\ 

(COMMAND  Diverge  s  •  undef  store)”;; 

■'i 

let  PROGRAM_DEF  -  new_def inition  ( •PROGRAM_DEF', 

"PROGRAM  (p;Program)  -  \n.lec  s  •  (update  'input'  n  newstore)  in 
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IwC  ci'  =  .COMMAND  p  s)  in  (access  'outpuc'  s')’)!) 


. — .  % 

t;ii  1_"  jc .  ml  », 

5c\£ic  TacEics  for  Reasoning  in  impl  ’h 

% 


ljjd_::heory  'impl';; 

■map  lo.adf  [  ‘  i;!iar!:_groups ' :  ' scring_rules ' ;  'digit' ; 'decimal '  1  ;  : 
•Ln'.'l'ide_r.heory  '  impl ' :  ; 

1  :  .\'!f  '  .  packages/hol/sun3/CacClcs/local/odd' ;  ; 
i  j.i'lf  '  .'packages/hol/sun3/Cactics/local/asm' ;  ; 


Tactics  Used  in  the  Proofs 


Ti 

% 

% 


let  jtf.:ng_tac 
le'  3TRIMG_.FUL£ 


CCW_TAC  (DE?TH_CONV  SCring_EQ_CON'/)  ;  ; 
:CMV_RULE  (DEPTH.CONV  sCring_Ei2_C0N\r')  :  ; 


let  TEC_EQ_TAC 
let  DEC_E',')_P,U1.E 


COfr/_TAC  (ONCE_DEPTH_CONV  DEC_Ei2_C0NV)  ;  ; 
COtrV_RULE  'ONCE_DEPTH_CONV  DEC_EQ_CONV!  ;  ; 


let  DEC_ADD_TAC 
let  TEC_ADD_Rr.'LE 


CONV_TAC  10NCE_DEPTH_C0NV  DEC_ADD_CON'''/ )  ;  ; 
CONV_RULE  (ONCE_DEPTH_CON'/  DEC_ADD_C01T;)  ; 


MB  :  DEPTH_;CMV  diverges  here  % 


let  F'.TLEQ.TAC  r  CCN'/_TAC  (DEPTH_CONV  FUN_EQ_COtJV)  ;  ; 

let  rUN_EC;_RULE  =  COt'IV_ROLE  (DEPTH_CONV  FUN_EQ_CONV)  ;  ; 


1  -t  ;;.mmand_  ;A3E3_TAC 


DISJ_CASES_THEN 

STRI P_ASSU>1E_TAC  (SPEC  t  ComiTand_cases )  THEN 
/A3M_REWRITE_TAC  (Command.distincc  1 )  ,-  ; 


t  =  DISJjlASES.THEN 

"  'ST-RiP.ASSUME.TAC  (SPEC  C  Store_casesi  THEN 
(ASM_REWRITE_TAC  (St0re_distinccl ) ;  ; 


elMPLlr Y_TAC  does  most  .of  Che  worit  in  simplifying  expressions  % 

let  :eF3  =  !lS_(;NrEFi:iED_DEF; 

:3_MUMBER_DEF: 

CET_NUM_DEF: 

ACCESS_DEF; 

','PPATE_DEF: 

:;E'/J3T0RE_DEF; 

N'imber_one_:'ne; 

Mumfaer_  ilstincc : 

3  CO  re_one_.one ; 

3r.ore_di£tinct: 

ADD_CLAUSES;  ’>  takes  care  of  trivial  arithmetic  % 

LEMMA2 1 ; ; 


let  3IMPLIFY_TAC  r 
REPEAT 

(CHANGED.TAC 

iASM_REWRITE_TAC  DEFS  THEN 
BETA_TAC  THEN 
STRING_TAC  THEN 
rium_EC:_TAC  THEN 
ADD_TAC  ORELSE 

ONCE_REWRITE_TAC  ( FIX_EQ1 ) ) ) ; 

=  REWRITE.TAC  (EXPR.DEF)  ; 


Let  EXPR_TAC 
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let  BOOL_EXPR_TAC  -  REWRITE_TAC  [B00L_EXPR_DEF1 ; ; 

le^  COMMAND_TAC  =■  REWRITE_TAC  [COMMAND_DEF;  SEQL_DEF ) ;  ; 

iec  ?ROGRAM_TAC  =  REWRITE_TAC  [LET_DEF;  PR0GRAM_DEF1  THEN  BETA_TAC 

let  RUNTAC  -  PROGRAM_TAC  THEN 

COMMAND_TAC  THEN 
aOOL_EXPR_TAC  THEN 
EXPR  TAC;; 
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APPENDIX  B 

Example:  Natural  Semantics  in  Isabelle 


: i . mi  ; 

iper-'ic ionai  Semancics  for  a  Functional 
Language  with  Recursion 


Va  r  ■  ’  , 


?r "  1 . 
Ar-piV  *  1 


.  lAtermi - >  Atertn)  ,  (*  expressions 

'Aterm!  - >  Aterm) . 

;Aterm,  Aterm) - ->  Aterm!, 

,  [Aterm,  Aterm)  - >  Aterm), 

[Aterm,  Aterm,  Aterm)  - >  Aterm) , 

[Aterm,  Aterm)  - >  Aterm), 

[Aterm,  Aterm)  — >  Aterm), 


•) 


[Aterm,  Aterm)  - >  Aterm) , 

[Aterm,  .Aterm) - >  Aterm) 

[Aterm,  Aterm)  — »  Aterm), 
[Aterm)  --->  .Aterm)  , 


(•  declarations 


.  , 

eriv' .  ,  AtVF*^)  . 
ide').  Atype) , 
value"  !,  Atype), 
expr’i,  Atype? , 
ueci* i ,  rttype) , 


■  [  "^mpty  ! ,  Aterm;.  {•  environment  constructors 

["tind"!,  [Aterm,  Aterm,  Aterm)  - >  Aterm), 

["looioip"].  [Ater.m,  Aterm,  Aterm) - >  Aform)  ,  auxiliary  fns 

.[■combine'),  [Aterm,  Aterm,  Aterm]  - >  Aform), 

i  "unfold"  ]  ,  [Aterm,  Aterm,  Aterm) - >  Aform), 


val’i,  [Aterm).. - -  i^ierm)  ,  (*  value  constructors 

pair"),  [Aterm,  Aterm)  — >  Aterm) , 

clcsure"),  [Aterm.  Aterm,  Ate^m,  Aterm)  — >  Aterm) 


ii "const"),  [Aterm)  - >  Aterm) , 

ii"tt"l.  Aterm),  i*  ccnstants  *) 

[■ff'i,  Aterm), 

(["plus"),  ,Aterm), 

•:[  "minus"  1,  Aterm), 

; [ 'times " ) ,  Aterm)  , 
ii'tero"],  Aterm), 

[["apply"),  [Aterm,  Aterm,  Aterm)  - >  Aform) , 

;["seq").  (Aterm,  Ater.m,  Aterm) - >  Aform),  (*  expr  sequent  ') 

[[■seq'"),  (Aterm,  Aterm,  Aterm) - >  Aform),  (*  decl  .sequent  ♦) 

[["equiv"),  [Aterm, Aterm)  - >  Aform)  ) ;  {•  expression  equivalence  ') 

v.al  f3_thv  = 

extend_cheory  arith_chy  "fl* 

;["env,  "ide",  "v.alue",  "expr",  "decl",  "conscanf],  consc_decs) 

[  ( ■Const_cype" , 

•c  :  constant  *«>  Const  (c)  •.  expr*), 

( ■ Var_type" , 

■X  :  ide  ==>  Var  (x)  :  expr*), 

( ■Pr_type" , 

■[t  el  :  expr;  e2  :  expr  I]  ==>  Pr  (el,e2)  :  expr"), 

( ■ Apply_typa* , 
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“[I  el  :  expr;  e2  :  expr  1]  ==>  Apply  (el,  e2)  :  expr") , 
("Ifcype", 

“■I  el  :  expr;  e2  :  expr;  e3  :  expr  I]  — >  If(el,e2,e3)  :  expr"), 
("Fn_type“, 

"[lx:  ide;  e  :  expr  I]  =■»>  Fn(x,e)  :  expr"), 

("Lec_type", 

"[1  d  :  decl;  e  :  expr  II  =->  Lee  (d,e)  :  expr"), 

("Vai_;ype", 

"[i  X  :  ide;  e  :  expr  I]  ==>  Val  (x,e)  :  decl"), 

("Comp_type", 

"[i  dl  :  decl;  d2  :  decl  '1  ==>  Comp  (dl,  d2)  :  decl"), 
(“And_type", 

“[I  dl  :  decl;  d2  :  decl  1]  ==>  And  (dl,  d2)  :  decl"), 

("Rec  type", 

"d  :  decl  ==>  Rec  (d)  :  decl") , 

("tt_type", 

"tt  ;  constant"), 

("f f_type", 

"ff  :  constant"), 

("plus_type", 

"plus  :  constant"), 

("minus_type ", 

"minus  :  constant"), 

("times_type", 

"times  :  constant"), 

( "zero_type" , 

"zero  :  constant"), 

("empty_type", 

"empty  :  env"), 

( "bind_type " , 

"[I  E  :  env;  x  :  ide;  v  :  value  I)  ==>  bind  (x,  v,  E)  :  env"), 
("val_type", 

"c  ;  constant  ==>  val  (c)  :  value"), 

("oonsc_type", 

"n  :  nat  ==>  const  (n)  :  constant"), 

("pair_type", 

”[l  vl  :  value;  v2  :  value  i]  =•>  pair  (vl,v2)  :  value"), 
("closure_type", 

"[;  X  :  ide;  e  ;  expr;  E  :  env;  E'  :  env  ll  ==>  \ 

\  closure  (x,e,E,E')  :  value"), 

("Const_rule", 

"[i  E  :  env;  o  :  constant  i]  ==>  seq  (E,  Const  (c) ,  val  (c) ) "  ), 
("Var_rule", 

"[I  E  :  env;  x  :  ide;  v  :  value  ;  loolcup  (x,  E,  v)  1)  \ 

\  ■==>  seq  (E,  Var  (x),  v)"), 

("Pr_rule", 

"(I  E  :  env;  el  :  expr;  e2  :  expr;  vl  :  value;  v2  :  value;  \ 

\  seq  (E,el,vl);  seq  (E,e2,v2)  11  =->  \ 

\  seq  {E,  Pr(el,e2),  pair (vl , v2) ) ") , 

("Applyl_rule", 

" [ I  EO  :  env;  E  :  env;  E'  :  env;  E' '  :  env;  E' ' '  :  env;  \ 

\  e  :  expr;  el  :  expr;  e2  :  expr;  \ 

\  V  :  value;  v'  :  value;  \ 

\  seq  (EO,  el,  closure (x, e, E, E' )) ;  seq  (E0,e2,v);  \ 

V  unfold  (E',E',E");  combine  (E,  E",  E"')  ;  \ 

\  seq  (bind  (X,  V,  E' ' ' ) ,  e,  v')  I)  \ 

\  =->  seq  (EO,  Apply (el , e2) , v' )") , 

("Apply2_rule", 

"(I  E  :  env;  el  :  expr;  e2  :  expr;  \ 

\  V  :  value;  v'  :  value;  c  :  constant;  \ 

\  seq  (E,  el,  val(c));  seq  (E,e2,v);  \ 

\  epply  (val (c) , V, V' )  I]  \ 

\  ”•>  seq  (E,  Apply (el , e2) ,v' )") , 

("Ifl_rule", 

“ t I  E  :  env;  el  :  expr;  e2  :  expr;  e3  :  expr;  \ 

\  seq  (E,el,  val  (tt)  )  ;  seq(E,e2,v)  I)  \ 

\  — >  seq(E, I f (el, e2, e3) , V) ") , 

("If2_rule", 

" [ I  E  :  env;  el  :  expr;  e2  :  expr;  e3  :  expr;  \ 

\  seq  (E,el,  val  (ff) ) ;  seq(E,a3,v)  l|  \ 

\  -->  seq(E,  If  (•l,e2,«3) ,  V)  ") , 

("Fn_rule", 

"Tl  E  :  env;  x  :  ide;  e  :  expr  ll  -->  \ 

\  seq(E,  Fn(x,e),  closure(x, e,E, empty)  )■) , 


t 


« 
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E  :  t;nv;  S’  ;  env;  E’ '  :  ep.v;  d  :  decl;  e  :  •ixpr;  '■ 
.■e:;’  E,  d,  E');  combine  !E,  S'.  E’’);  \ 

,E' '  ,  e..  vj  I  > seq  (E,  Lee  fd,e),  v)  ■?  , 


E  :  env;  :<  :  ide:  e  ;  e:<pr;  seq  (E,  e,  v)  l]  \ 

=  =  >  r-:eT  !E,  Val{x.e).  bind  (x,  v,  empty)  )■)  , 

■T-t’lle", 

;  E  ;  env;  E'  :  env;  El  :  env;  S2  :  env;  E3  :  env;  \ 
il  led;  d2  :  decl  ;  \ 
eeq'  :e  ,  dl,  El);  combine  ,(E,  El,  E' ) ;.  \ 
ceq'  lE’V  d2,  E2) ;  combine  (E1,E2,E3)  1)  ==>  \ 
ceq'  1 E,  Comp  ;dl.'12),  E3)‘), 

:l_ru:e' . 

;  E  :  env:  E'  :  env;  El  :  env;  E2  :  env;  E3  :  env; 

11  :  led:  12  :  decl  :  \ 

ceq'  ;E  ,  dl,  El);  seq’  ;e,  d2 ,  E2);  Combine  (E1,E2 
c-q"  .'E,  And  idl,d2),  E3)  •)  , 


E  :  env;  E'  ;  env;  E' '  ;  env;  d  :  decl  ;  \ 

inrdd  ,E,E’,E'’):  seq’lE.d.E')  I)  ==>seq’  (E,  RecMi.E"  ’ 
.pl_r';le* , 

E  :  env;  X  :  ide;  V  :  value  i)  ==>  \ 

;x';p  .X,  bind  'x,  v,  E) ,  v)  •  ), 

;?2_rule* , 

E  :  env;  X  :  ide;  ■/  :  ide;  v  :  value  ;  \ 

:  value;  "ly  =  X  ;  ide);  locxup  (x,  E,  v)  i)  \ 

>  Iccidp  iX,  bind  (y,  E)  ,  •/)  •  ). 
ne_empcv* , 

env  ■==>  cenbine  (E,  empty,  E)‘), 
ne_bind’ , 

El  ;  env;  E2  :  env;  E3  :  env;  X  :  ide;  a  ;  value; \ 

'.-riir.e  .E1,E2,E3)  !]  ==>  \ 

.'.rbir.e  ',E1,  bind a. E2)  ,  bind  (x,a,E3))’), 
l-e.-pcy. 

-nv  =■=■•  .r.iold  E,  empty,  empty)"). 

E  :  env;  El  :  env;  E2  :  env;  E'  :  env;  E'  '  ;  env; 
f  :  ;’:e;  x  :  ide;  e  :  expr;  unfold  (E.E'.E'M  II  ==> 

;r.:cld  E,  bind(  f .  clcsurelx,  e,  El,  E2)  ,  E’ ) ,  \ 
nint! ;  dccureix,  e.  El,  E)  ,£'■))") , 


■pluc_:  de" . 

m.  :  nat;  n  ;  nat  l)  ==>  \ 

ipply  :vai;plU3).  pair  (val  •: const  (m) )  ,val  (const  (n)  ))  , 
v\l (const (m»-ni > ) • ) . 

"minus^rule* , 

m  :  nat;  n  :  nat  ;)  \ 

ippi-V  (vaKminus),  pair  {•.•al  (const  (m) )  ,val  ( const  (n) )),  . 
val (const (m-n) ) ) " ) , 

.  •••.ic,es_ruie" , 

■  ;  i  .-q  :  nat;  n  .■  nat  !)  -r>  \  ' 

apply  (val  (times),  pair  (val  (const  (m)  ).  val  (const  (n)  )). '. 
val [const ,m#"n) ))•) , 

•cercl^rule* , 

•apply  {vaKcero)  ,  ’/al (consCiO) )  .  val(ct))"), 

.  *  tero2^rule" , 

■n  :  nat  ==>  apply  (vaKtero).  val (Succ (n) ) ,  val(ff))'), 
;  •equi’ddef  • . 

"equiv  (el,  v2i  --  ALL  E  :  env.  ALL  v  ;  value.  \ 

\  seq{E,el.’/)  <->  seqCE, e2,'/)  * )  1  : 


val  Const_type  =  qet_axlom  f3_chy  •Consc_cype" ; 
val  Var_type  =  get_axiom  f3_thy  ■Var_type": 
val  Pr_type  =  :!et_axiom  f3_chy  •Pr_type": 
val  Apply_type  =  get_axiom  £3_thy  ■Apply_type" ; 
val  I£_type  s  get.axiom  f3_chy  •If_cype"; 

val  Fn_type  =  ■jBt_axiom  f3_thy  ■Fn_type"; 

val  Let_type  =  yet_axlom  f3_thy  •LeC_type*; 

v,'<i  val_type  »  ■3et_axiom  f3_chy  •Val.cype"; 

val  comp_type  a  get_axiom  f3_thy  •Comp_cype*) 
val  And_type  =  get_axiom  £3_thy  •And_cype"; 

val  Rec_type  =  get_axiora  f3_thy  •Rec_type": 

val  empty_type  a  get_axiom  f3_thy  •empty_cype" ; 
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val  tt_cype  =  get_axiom  f3_;:hy  “tt_type“; 
val  ff_!;ype  =  gei;_axiom  f3_thy  “ff^type"; 
val  plus_iype  get:_axiora  f3_thy  "plus_type“; 
val  T.ir.'js_cype  =  get_axiom  f3_thy  "minus_Cype"; 
val  times_type  =  gec_axiom  f3_thy  “tiraes_type"; 
val  zero_tLype  =  get_axiom  f3_thy  “zero  type"; 

val  bind  cype  =  get_axiom  f3_thY  "bincl_type"; 

val  val  type  *  gec_axiom  f3_thy  "val_type"; 

val  corsc_type  *  get_axiom  f3_chy  "consc_type"; 
val  pair_type  =  get_axiom  f3_thy  "pair_type"; 
val  closurecype  =  getaxiom  f3_thy  "closure_type”; 


val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 

val 


Const_rule  =  get_axiom  f3_thy  "Const_rule“; 

Varrule  =  get_axiom  f3_thy  "Var_rule"; 

Pr_rule  =  geC_axiom  f3_thy  "Pr_rule“; 

Applyl_rule  =  get_axiom  f3_!:hy  "Applyl_rule"; 

Apply2_rule  =  get_axiom  f3_thy  “ Apply 2_rule"; 

Ifl_rule  =  gec_axiQm  f3_t:hy  "I£l_rule”; 

If2_rule  =  gec_axiora  f3_thy  “If2_rule"; 

Fn_rule  =  get_axiom  f3_chy  "Fnrule"; 

Lec_rule  =  get_axiom  f3_t.hy  “Lec_rule"; 

Valrule  =  getaxiom  f3_thy  “Valrule"; 

Comp_rule  =  get_axiom  f3_chy  ”Comp_rule"; 

And_rule  =  get_axiom  f3_thy  “And_rule“; 

Rec  rule  =  get  axiom  f3_thy  '’Rec_rule"; 

lookupl_rule  =  get_axiom  f3^thy  " loo)cupl_rule''; 

lookup2_rule  =  get_axiom  f3_thy  "lookup2_rule"; 

combine_empty  =  get_axiom  f3_thy  "combine_empty " 

combine_bind  =  get_axiom  f3_thy  "combine_bind"; 

unfold_empty  =  get_axiom  f3_thy  "unfold_empty"; 

unfald_bir.d  >■  get_axiom  f3_thy  "unfold_bind"; 

plus_rule  =  get_axiom  f3_thy  “plu3_rule“; 
minus_rule  -  get_axiom  f3_thy  ”minus_rule"; 

tir"es_rule  =  get_axiom  f3_thy  "times_rule"; 

zerol_r'jle  =  get_axiom  f3_thy  “zetol_rule'’; 

zero2_rule  =  get_axiom  f3_thy  “zero2_rule'’; 

equiv_def  -  get_axiom  f3_thy  "equiv_def"; 


(»  - 

(•  inference  rules  for  sequents  in  the  language 
(’  - - 


val  expr_rules  =>  ;canst_rule,  Var_cuie,  Pr_rule,  Applyl_rule,  Apply2_rule, 
Ifl_rure,  I£2_ruie,  Fn_rule,  Let_rule); 

va.  decl_rules  =  iVai_rule,  Comp_cuie,  And_rule,  Rec_ruleJ; 

val  ianq_rules  =  d«cl_cules9expc_cules; 


(.  -  ,, 

(*  basic  reduction  rules  •) 

('  - - - - - - - - . - . —  -  ') 


val  lookup_rules  =  [ lookupl_rule,  lookup2_rulei ; 

val  combine_rules  *  [combine_bind,  combine_empty 1 ; 

val  unfold_rules  »  [unfold_bind,  unfold_empty | ; 

val  basval_rules  »  tplus_rule,  minus_rule, 

times_rule,  zerol_rule,  zero2_rulel; 


(•  . . . . . . . . •) 

(*  simplification:  basic  logical,  arithmetic  and  typing  rules 
(•  . . 


val  HOL_rules  -  [refl,  dlff_0_eq_0,  add_convO,  dlff_convO, 
conj_lncr,  dlsj_intrl,  disj_lntr2, 
iff_intr,  True_lntrl; 

val  HOL_type_rules  -  arith_type_rlsl (Succ_type,  Zaro_type); 
val  fl_type_rules  ■ 
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::;.n3C_type,  Var_cype,  Pr_cyp«,  Apply_cype,  lJ_Eype,  rn_’-,7pe, 
[-e!:_typ9,  Val._i;yp9.  Comp_type,  And_type,  P.ec_tyVe, 
-,T!pEy_'.vT9,  blnd_P.yp9,  !;c_cype,  ff.eype, 
pi‘;;;_pyi.^,  rtilnua_t;yp9,  t;lmes_cype,  zero_cype, 
v.,l_-.yp*,  oon.sr._cype,  pair_cype,  ':losur®_cype] ; 


(• 
( • 


'  L-\e 

IS  =  goal  f3_thy 
y  :  ide;  Z  :  Ide;  f 

ide;  g  :  ide;  \ 

"  X  X  =  y 

ide) 

"(y  =  X  :  ide) 

\ 

'  ( X  =  1 

ide) 

■(z  =  X  :  ide) 

\ 

'{X  =  f 

ide) 

-(f  =  X  !  ide) 

\ 

' ;  X  =  g 

ide). 

.  '(g  =  k  ide)" 

\ 

fl 

II 

'{z  =  y  :  ide) 

\ 

i  y  =  t 

ide) 

■{f  =  y  :  ide) 

\ 

' \y  =  -j 

ide) 

"(g  =  y  :  ide) 

\ 

';f  =  : 

ide) 

■'z  =  f  :  ide) 

\ 

ide) 

'{z  =9  :  ide) 

\ 

"it  =  .f 

ide) 

'(g  =  f  ;  ide) 

\ 

m  :  na  t ; 

n  :-nat;  \ 

:  v.-ilue;  b  : 
e  ;  -ifXpr;  *r'  : 

value;  \ 
expr:  E  :  env 

II 

II 

V 

i 

Jirr.p_i-;1-.' 

=  co: 

■uT,Qn_asms  4  H0L_rule3  4  HOL_type_rules 

caccica.ml 

pacclcs  for  proving  programs  In  f3 


r'iicrir.ir.acor^i  for  dubgoals.  These  are  used  co  make 
c'lre  ohac  ■.>nly  ^'afe  resolution  rules  are  used 


fj_tr.y  :E,?e,:v)*; 

val  j  r  ^jetiioai  i: 

;-in  ;i-_S9T  n  =  ;ould_uni£y  ig,  t); 

-Ml  :3_thy  'oeg'  ( ?£,  fixvar,  ?E)  •  ; 
val  g  =  ;;eC.ioal  1; 

fur.  is_safe_.':eq'  c  =  (is_seq'  t)  andalso  not  (could_unify (g,  O); 

j:  ai  £?._t.hy  "seq  ( ?E,  ?e,  ?v)  •  ; 

val  g  =  getgoal  1; 

fur  is_seq  t  =  could_unify  (g,  t) ; 

goal  f?_thy  'seq  { ?E, fixvar , ?E) * ; 
val  g  I  getgoal  1; 

fun  is_3afe_seq  t  i  (is_seq  t)  andalsq  not  (could_unify (g,  t)): 

val  :3_seq'uent  =  fn  =>  {is_seq  t)  orelse  (is_seq'  t)  ; 

val  is_3a£e_3equent  =  fn  t  =.>  :is_safe_seq  t)  orelse  ( ls_saf e_seq '  t)  ; 


goal  f3_thy  "combine  ( ?E, 7E, ?E) " ; 
val  g  =  getgoal  1; 

fun  is_combine  t  =  could_unify (g,  t) : 

goal  f3_chy  "combine  ( ?E, fixvar, ?E) " ; 
val  g  =  getgoal  1;_  -  — 

fun  Isrsafe.combine  t  =  (is_comblne  t)  andalso  not  tcould_unify  (g,  t)),- 

goal  f3_thy  "unfold  ( ?E, ?E, ?E) • ; 
val  g  =  getgoal  1; 

fun  is.unfold  t  =  could_unify (g,  c) ; 

goal  f3_thy  "unfold  (7E,fixvar, 7E) •; 
val  g  =  getgoal  1; 

fun  i3_safe_unfold  c  ■  (is_unfold  t)  andalso  not  (could_unlfy (g,  ti); 

goal  f3_thy  "lookup  (7x,7E,7v) •; 
val  g  =  getgoal  1; 
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fun  is_lookup  t  =  cQuld_uni £y (g,  t); 

goal  f3_thy  “lookup  (7E, fixvar, ?E) 
val  g  >!  gecgoal  1; 

fun  is_safe_lookup  c  =  (i3_lookup  t)  andalso  not  <could_unify (g,  t)); 
fun  outgoai  i 

fn  state  =>  let  val  t,_)  =  dest_stace ( state, i )  in  t  end; 


(.  -  .) 

(*  NOT_APPLICABLE  fails  when  there  is  a  subgoal  for  which  *) 
(*  a  given  selector  is  true,  and  succeeds  otherwise  ') 
(' - -  •) 


fun  N0T_APP1ICA3LE  selector  = 
let  fun  tac  (i,n,  state)  = 
if  i>n  then 
all_tac 
else 

if  (selector  (outgoai  i  state))  then  no_tac  else  tac  (i+l,n,  state) 
in  Tactic(fn  state  => 

tapply  (tac  (1,  length  (preTns_of  state),  state),  state))  end; 


(.  -  .) 

(•  rlHSTONLY  chooses  the  first  subgoal  for  which  the  selector  •) 
(’  function  is  true;  it  then  applies  the  given  tactic,  and  *) 
(*  fails  otherwise  *) 
(• - - - - - - -  M 


fun  EIRSTONLY  selector  t£  = 
let  fun  tac  (i,n,  state)  = 
if  i>n  then 


no  tac 


else 

if  (selector  (outgoai  i  state))  then  tf(i)  else  tac  (i*l,n, 
in  Tactic(fn  state  -> 

tapply  (tac (1,  length  (prems_of  state),  state),  state))  end; 


state) 


I 


- - - - -  •) 

('  reduction  tactics  ’) 
('  ') 
('  lookup  tac;  reduces  using  the  lookup  rules  •) 
(’  '  •) 
(•  conibine_tao;  reduces  using  rules  for  ') 
('  co.Tbining  environments  *) 
(’  •) 
('  unfola_tac:  reduces  using  rules  for  'I 
('  unfolding  environments  *) 
(*  •) 
(•  ba3val_tac:  reduces  using  the  rules  for  predefined  ') 
(•  constant  functions  •) 
(•  *) 
('  reduce  tac:  performs  a  sin.g.e  reduction  *i 
(•  ~  •) 
(.  - - - 


val  lookup_:ac  • 

FIRSTONLY  i s_sa fe_lookup  (resolve^tac  lookup_rules  ); 
val  comblne_tac  • 

FIRSTONLY  is_safe_combir,e  (resolve_tac  combine_rules) ; 
val  unfoid_cac  ■ 

FIRSTONLY  ls_safe_unfold  (resolve  tac  unfold_rules) ; 
val  basval_tac  -  FIRSTGOAL  (resolve_tac  b4sval_rules) ; 
val  roduce^tac 

loolcup_£ac  ORELSE  combine_tac  ORELSE  unfold_tac  ORELSE  basval_tac; 


. . - . — - - - —  •) 

(*  step  tac:  applies  a  language  rule  once,  and  safely  *) 

. . - - - - - •) 


I 


i 


I 
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v.h;  -  FIR3TOHLY  l2_SAf'S_a«tiuenc  Cr«aolv*_t«'J  lan'3_r'ile’£:;  ,■ 


;  fjrjw-if.'isdly’  Applies  r.h«  langua'34  rules, 
,;irr -irylnfl  (ft-ir  -iach  ^cep  if  possible 
:■  f  ills  if  -iny  sequencj  remain 


.Ml  1  =  REf'EATl  (scep.ifac  THEM  TRY  (P.EPEATl  reduce_:;ac) 

:10T_APPL,ICAELE  Is.sequenC: 


jirr'.p_'.ac ;  pr-ives  r.he  -joal  by  repeated  assumptions 
and  use  of  the  type  information 
•-■ntained  in  the  premises. 


■•Mi  simp_tac  =  REPEAT  i'are3_tao  3imp_rules  1)  ; 


fj_tAC:  jencral-purpose  tactic  for  proving  goals  by 
lepith-fiist  search 


A  PEFTH_f:p.3T  (haE_fewer_prems  1) 

:lang_cac  THEN  3imp_tac) ; 
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APPENDIX  C 

Example:  IVansIator  for  FIJNC3 


/.  -  ./ 

/ '  Iranslace.y  '/ 
/'  yacc  source  code  for  converting  between  programs  */ 
/'  expressed  in  a  simple  functional  language  to  •/ 
/ *  suitable  goals  for  Isabelle's  HOL  '/ 
/»  -  ./ 


%{ 

♦include  "t ranslate . h" 

%) 

%start  text 
%union  ( 
int  num; 

St  ring  str; 

%taxen  <str>  NUMBER  I3ENTIFIER  PAIR  APPLY  IF  THEN  ELSE  FN  LET  IN  TRUE  FALSE 

%to'xen  <str>  VAL  COMP  AND  REC  COMMENT  TURNSTILE  EMPTY 

%to:<en  <str>  ENV  EVAL  SCHEME  ZERO  ML 

itype  <str>  expr  bexpr  decl  env  bindlist 

%:e'ft  ■*' 

%left 

text:  / '  nothing  '/ 

text  comment 
text  query 
text  ml 


comment:  COMMENT  i  fprintf  (outfile,  “%s’',  SI);  ) 


query:  env  TURNSTILE  expr  EVAL  SCHEME 
•,  fprintf  (outfile, 

"'ngoal  f3_thy  \n\"seq(»s,  is,  %s)  \";  by  f 3_tac; \n\n",  SI,  S3,  S5);  ) 
env  TURNSTILE  decl  EVAL  SCHEME 
(  fprintf (outfile, 

"Vgoal  f3_thy  \n\"seq' (<s,  %s,  %s)  \“;  by  f3_Cac;  \n\n",  SI,  S3,  55); 


ML  1  fprintf (outfile,  "ls\n",  51);  I 


env:  ']'  (  SS  -  make_nul lop (EMPTY) ;  ) 

'  ! '  bindlist  '  1 '  (  5S  =■  S2;  ) 


oin.dlist:  '('  IDENTIFIER  NUMBER  ')' 

;  SS  =  ma)ie  binop  (ENV,  S2,  .r..  y;e_vaiue  (NUMBER,  S4) ) ;  ) 
bindlist  ' ('  IDENTIFIER  NUMBER  ')' 

(  55  »  make_ternop  (ENV,  54,  ma)te_value  (NUMBER,  56)  ,  51);  ) 


expr:  NUMBER  (  55  =  ma)te_number  (SI);  ) 

IDENTIFIER  (  55  -  m.a)te_ nop  (IDENTIFIER,  Slj;  ) 

;  expr  expr  (  55  malte_F  •  nop  (PAIR,  51.  S3);  ) 

I  expr  expr  (  55  -  mako_binop  (APPLY,  51,  52);  ) 

I  IF  bexpr  THEN  expr  ELSE  expr 

{  55  -  malte_ternop  (IF,  52,  54,  56);  I 
(  FN  IDENTIFIER  expr  (  55  >  roalte_binop(FN,  52,  54) ;  ) 

I  LET  decl  IN  expr  I  55  •  ma)ce_binop(LET,  52. 54) ;  ) 

I  expr  ' expr  (  55  •  malta_blnop  (APPLY,  raako_nullop  { '  ♦’ ) , 

m4ke_binop  (PAIR,  $1,  S3));  ) 

1  expr  expr  (  55  •  rnake_blnop  (APPLY,  make_nullop(' •' ) , 

makeblnop  (PAIR,  51,  S3));  ) 

I  expr  expr  (  SS  •  make_blnop  (APPLY,  ma){e  nullop('-'), 

makeblnop  (PAIR,  $1,  S3));  ) 

I  '  ('  expr  ' ) '  (  SS  »  $2;  ) 
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L>j:-:pi  ;  TRUE  [  iO  s  malc@_rmllop  (TROE)  <  t 

;  TALSE  (  JS  a  make_niiHcp  (FALSE);  ) 

EERO  -!:-:pr  {  ;s  »wa)ce_blnop  (APPLY,  ma)ce_nullop (ZERO) ,  $2 ;  ;  i 

■ : •  b^vpr  - ■ ■  {  IS  =  52:  ; 


■/AL  rOENTIF'ER  '  =  ‘  expr  (  SS  =  make_binop  (VAL,  52,  54); 
Iricl  i«cl  (  55  =  maice_binop  (COMP,  SI,  53);  ) 
led  AMD  led  (  35  =  malce_binop  (AND,  51,  S3);  } 

RET  lied  f  55  =  ma)ce_'incp  (REC,S2);  3 
'  !  '  led  •  1  ■  (  55  =  52;  ) 


FILE  •Infile  :  :5cdin; 

FILE  ’outfile  =  jr.louc; 

ir.“  lineno; 

ri'.ain  largc,  argv) 

.-■iiji  •  atgv  [  1  ; 

yypar;ie( )  ; 

.'br  ir.'j~make,.ri'imbet  iru 
Er.rinj  n; 

:r,:  b'-;5.n:e  =  jctlenin)  ♦20; 

5-.rir.g  b  =  (String)  balloo  .bufsUe); 
,;pri.n!:£!t,  •Cc'n;5C  :  rtnst;  ('^s)  )  * ,  n)  ; 
return  t; 


string  salte.value 
, '  ■  :  i  n  :t  2  ; 

lur.  Lu£2i:e  -  jcrlen(s) -20; 

String  t  =  'String)  nalloc  (bufsite)  : 
..'witc.dd 

I 

•.-ase  LUMBER: 

uprintfit,  'vd  .  roast  ,l3)  S  • ,  s);  brealt; 
return  t; 


..'■ring  rta;te_nullop  .c; 
t 

int  bufsite  =  2'>; 

String  c  =  (String)  .tiallcc  (bufslze)  ; 
switch (c) 

I 

•ise  TRUE: 

sprintfit  , 'Const . tt I  *  . ;  iieak; 
rase  FALSE: 

sprintilc  ,'Const':£)'  ;  tirealc; 

rase  ' ♦ ' : 

sprintflt  , 'Const  (plus)  ■  l;  breait; 
case  ' • ' : 

sprint £(t  , 'Const  (ti, Ties)  •  );  brea)c; 
ri^se  *  -  ‘  : 

sprlntf(t  ,  "Const  (tilnusj  ■  )  ;  brealc; 
case  ZERO: 

cprintfit  , 'Constitero)  •  );  brealt; 
case  EMPTY: 

sprintf(t  , 'empty*  );  brea)t; 

) 

return  t; 

) 

string  n:ak«_unop  (c,s) 

int  c;  .  7 '7  •  — 

String  s;  . 
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{ 

int  bufsize  =  strlen  (s)  ■*•20; 

String  t  =  (String)  malloc  (bufsize); 
switch  (c) 

( 

case  IDENTIFIER: 

sprintf(t,  "Var  (%s) ",  s);  break; 
case  REC: 

sprintflt,  "Rec  (%s)",  s) ;  break; 

} 

return  t; 


String  make_binop  (G,tl,t2) 
int  c; 


String  tl,  t2; 

{ 

int  bufsize  =  strlen  (tl)  ■•■scrlen  (t2)  ■♦•20; 

String  t  =  (String)  nalloc  (bufsize); 
switch  (c) 

{ 

case  FN: 

sprintfft  , "Fn  (%s,  %s) "  ,  ti,  t2);  break; 
case  APPLY: 

sprintf(t  , "Apply  (%s,  %s)"  ,  tl,  t2);  break; 
case  PAIR: 

sprintf(t  ,"Pr  (%s,  %s)"  ,  tl,  t2);  break; 
case  LET: 

sprintf(t  ,"Let  (%s,  %s)"  ,  tl,  t2);  break; 
case  VAL; 

sprintf(t  ,"Vai  (%s,  %s)''  ,  tl,  t2);  break; 
case  COMP: 

sprintf(t,  "Comp  (%s,  %s)'',  tl,  t2);  break; 
case  AND: 

sprintf(t,  "And  (%s,  %s)",  tl,  t2);  break; 

■case  ENV: 

sprintf(t,  "bind  (%s,  tss,  empty)",  tl,  t2);  break; 


return 


String  make^ternop  (c,tl,t2,t3) 
int  c; 

String  tl,  t2,  t3; 

{ 

int  bufsize  =  strlen  (tl)  ■♦•strien  (t2)  ■♦•strlen  (c3)  *-20; 
String  t  =  (String)  malloc  (bufsize); 
sw 1 1  ch  (c) 


case  IF: 

sprintf(t,  "If  (%s,  %s,  %s)",  tl,  t2,  t3);  break; 
case  ENV: 

sprintf(t,  "binct(%s,  \s,  %3)",  tl,t2,t3); 


yyerror (s) 
char  *s; 

fprintf (stderr,  "  %s  near  line  %d\n",  s,  llncno); 

} 


/•  — . - . —  */ 

/•  lex.l:  lexical  analyser  */ 

. . . 


»( 

extern  int  lineno; 
llnclud#  "translate. h" 
tincluda  "y.tab.h* 


< 
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i  -.n.'  I  1  iiieno*-* ;  ) 

'<-•  ■  '.'rr.ntn  TURNSTILE  ;  I 

■  =  I  I'lCiitri  EVAL;  ) 

■  ■■.  ■  *  I  t“CUtn  FN;  } 

■il'  :rr.'!rn  IF;  ) 

THEN;  ) 
rr-r.'itn  ELSE;  ) 

I  i<=!Curn  LET;  ) 

•ir.‘  (  t-jr.i.itn  IN;  1 

■  I  ;-cutn  AND;  ) 

"r.r'ie"  ■'  r^cujn  TRUE;  ! 

'  r-sC’icn  FALSE;  ) 

■val"  i  r-curn  VAL;  ) 

■i-iro'  I  rocurn  "ERO;  ) 

•t-rc"  ■  r-?r.urr.  REC;  ) 

”  \ Ui-:A-D!  (  yylval.scr  = 

(Scring)  malloc  (yyleng) ; 
scrrpy  !yylval.scr,  yytexc) ;  recurn  SCHEME;  ) 
f  yylval.scr  = 

f String)  malloc  (yyleng); 

:;r,rcpy  lyylv.il ,  scr,  yycexc) ; 
rec'irn  UUxmemt;  ) 

*  yylval.scr  = 

(Scring)  malloc  (yyleng): 
scr.-r.''/  {yylval.scr,  yycexc  *  2): 

y'j^lv.il.scr  (yyleng-41  =  •'TO';'  /•  strip  brac)cecs  ♦/ 
yylv.vl'.icr  (yyleng-5|  = 
reC'iin  :-!L;  ) 

■Su'.-c !  :i)  ■  !  yylval.scr  =  (Scring)  malloc  (yyleng); 

.itrcpy  (yylval.scr,  yytexc); 
tecur.n  MUMEER;  ) 

(mni'l  '  IVlval.scr  =  (String)  .malloc  (yyleng); 
sctcpy  (yylv.ai.scr,  yytexc); 
return  LT'MBER;  ) 

;  i-:A-;i [a-cA-DO-iM  *  (  yylval.scr  =  (String)  malloc  (yyleng); 
s-crcpy  :yylval.scr,  yycexc).; 
return  IIENTIFIER;  ) 
return  yytexc  Id];  ; 


•  cr.anslace.h  '/ 

. . . . . 

»i'.’.:lurie  ..jcdio.h> 

■ycv'-ie:  char  *  Scring; 

string  maXe_n'jmber  (); 

String  ma);e_bool  ( )  ; 

String  raaXe_var  (); 
scring  maKe_value{ ) ; 

String  make_binop  : ) ; 
scring  ma);e_tfernop( ) ; 

.String  mK_empcy(); 

.String  niaite_env ( )  ; 
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